Die Software-Architektur SCA3D Adaptive 3D Visualisierung ... · Adaptive 3D Visualisierung und Kooperation in offenen Informationsraumen¨ Datum der Promotion (Tag der m¨undlichen

VomFachbereichfur MathematikundInformatikderTechnischenUniversitat Braunschweig

genehmigteDissertationzurErlangungdesGradeseines

Doktor-Ingenieurs(Dr.-Ing.)

JobstMichaelLoffler

Die Software-Architektur SCA3DAdaptive3D VisualisierungundKooperationin

offenenInformationsraumen

DatumderPromotion(TagdermundlichenPrufung): 16.Oktober2002

1. Referent:Prof.Dr. DieterW. Fellner2. Referent:Prof.Dr. Hans-JurgenAppelratheingereichtam:20.Marz2002

i

Abstract

Thiswork presentsthesoftwarearchitectureSCA3Dasaflexible framework for distributed3D visualizationwhich allows anextendedview on new conceptsfor managementof complex andprotected3D documents.Digital datahave a determininginfluenceon the modernwork flow from the first conceptionphaseto thefinal manufacturingof aproduct.In mostcasesthework flow is adistributedprocessin whichmultipleuserswork togetherin an environmentof networked computers.Requirementsfor distributedwork with digitaldata,which areregardedasdigital documents,arethefollowing: First,well-definedinterfacesbetweenpro-cessingsystemsareneededto allow cooperationanddataexchange.Second,methodsfor long-termstoragein archives,for retrieval andfor distributionof digital documentsarerequiredwhichareableto managehugeamountsof complex digital documents.Third, adaptationof multimediadocumentsduring distribution inheterogeneousenvironmentsmustbesupportedto controlnetwork andlocalprocessingload.

Digital libraries,understoodasopeninformationspaces,offer asuitableframework for describingsoluti-onsthatfulfill theaboverequirements.Heretheconceptof anopeninformationspaceis usedin thecontext ofdigital librariesto emphasizetwo points:First, thatdigital library servicesarenot restrictedto closedgroupsof usersandinformationservers.Second,that it is importantthat uniform conditionsfor accessto digitaldocumentsareprovidedthroughoutaninformationspaceandthatinterfacesto otherinformationspacescanbeestablished.

Themainfocusof thework presentedhereis theexplorationof new methodsfor distributedprocessingof 3D documentsin openinformationspaces.Threedimensionalscenes,asfor exampleCAD models,areconsideredto bedigital documentscontainingstructureinformation,geometriccontentanddescriptivemeta-data.Examplesof applicationsare:distributeddevelopmentof new productsin theautomotiveindustryusingdigital mock-ups,medicalinformationsystemsor cooperativelearningenvironments.Ontheonehandit canbeobservedthatthenumberof 3D documentsexchangedbetweenapplicationsis growing from yearto yearandthat their complexity increases.On the otherhandmodernworking environmentsarebecomingmoreheterogeneous.Thespectrumof systemsinvolvedin a work processcanrangefrom powerful workstationsin a localnetwork to mobileenddeviceswith restrictedprocessingpowerandconnectionbandwidth.

As a responseto this challengethis dissertationpresentsa softwarearchitecturefor distributed3D vi-sualizationthatsupportsdocumentfeaturesin opendistributedenvironmentsandprovidesfunctionalityformanagementof complexity andsecurityrequirementsof 3D documents.Thestatusquoof the researchondistributedsoftwarearchitecturesfor 3D visualizationis extendedby this work in two ways.First, it deve-lopsanew approachto supportinghybrid2D/3Dclientscenesin distributedandcooperativework processes.Second,it introducesnew methodsfor complexity andsecuritymanagementthat allow distribution of theprocessingload(rendering)andindividual controlof thenetwork load.In this context a new methodis al-sopresentedwhich enablesapplicationindependentaccessto distributed3D documents(documentrequestbroker). Thiswork describesthelevel-of-informationapproachthatwasdevelopedto makeit possibleto ad-apttransmissionrateandlocal processingloadusinga performancemetric.Finally, a gradedrightsconceptis part of thesoftwarearchitecture.This conceptguaranteestheprotectionof documentdataby controlleddisseminationof copieswith adaptedinformationcontent.

In practicetheresultsof this work provide new possibilitiesfor digital productdevelopmentprocesseswhichcannow useawidescaleof informationaboutthe3D scenesbeingworkedon.Thisscalerangesfromdescriptive metadatato the original 3D contentof a document.A scenariolike a distributeddesignreviewin a stronglyheterogeneousenvironmentwith multiple developersworking on complex andprotected3Ddocumentsis now supportedin amoredirectwaythanby approaches(full replicationapproach) whichhavebeenpreviouslyapplied.

ii

Zusammenfassung

Die vorliegendeArbeit stellt mit der Software-ArchitekturSCA3D einenflexiblen Rahmenzur verteilten3D Visualisierungvor, der einenerweitertenBlick auf neueKonzeptezum Managementvon komplexenundgeschutzten3D Dokumentenerlaubt.Digitale Datenbestimmenin immerstarkeremMaßmoderneAr-beitsprozessevon dererstenKonzeptionsphasebis zur FertigungeinesProduktes.Dabeihandeltessich invielenFallenum verteilteProzesse,die von mehrerenmitwirkendenPersonenmit Hilfe vernetzterCompu-tersystemedurchgefuhrtwerden.HierausergebensichAnforderungenfur dasverteilteArbeitenmit digitalenDaten,dienunalsdigitaleDokumenteaufgefaßtwerden:ErstenssollteesdefinierteSchnittstellenzwischenVerarbeitungssystemengeben,um eineZusammenarbeitunddenDatenaustauschzu ermoglichen.ZweitenswerdenMethodenzurLangzeitspeicherungin Archiven,zumRetrieval undzurVerteilungvondigitalenDo-kumentenbenotigt,diein derLagesind,großeMengenvonkomplexenDokumentenhandhabbarzumachen.SchließlichsollteeineAdaptiondermultimedialenDokumentezur KontrollederNetzwerklastundlokalenVerarbeitungslastbeiderVerteilungin heterogenenUmgebungenunterstutztwerden.

Digitale Bibliotheken verstandenals offene InformationsraumebieteneinengeeignetenRahmen,umLosungsansatzezur Erfullung dergenanntenAnforderungenzu beschreiben.In dieserArbeit wird derBe-griff desoffenenInformationsraumesfur digitale Bibliotheken verwendet,da einerseitsdie angebotenenDienstenicht auf vorherbekannteBenutzergruppenundInformations-Serverbeschranktsind.AndererseitsstehengleichformigeBedingungenfur denZugriff auf digitaleDokumenteim gesamtenInformationsraumzurVerfugungundSchnittstellenzuanderenInformationsraumenwerdenermoglicht.

Der SchwerpunktdervorliegendenArbeit liegt auf derUntersuchungvon neuenMethodenzur verteil-tenVerarbeitungvon 3D Dokumentenin offenenInformationsraumenundderenUmsetzungin Form einerSoftware-Architektur. DreidimensionaleSzenen,wie z.B. CAD-Modelle, werdenals digitale Dokumentemit Struktur, Inhalt und beschreibendenMetadatenaufgefaßt.Beispielehierfur sind die verteilteProdukt-entwicklungim Automobilbereichmit digitalenPrototypen(Digital Mock-Up),medizinischeInformations-systemeoder auchkooperative Lernumgebungen.Hierbei ist zu beobachten,dassdie Anzahl der ausge-tauschten3D Dokumenteundihre Komplexitat in derPraxisfortlaufendansteigt.Andererseitswerdenmo-derneArbeitsumgebungenimmerheterogener, wobeidasSpektrumbeteiligterSystemevomleistungsstarkenArbeitsplatzrechnerim lokalenNetzbishin zummobilenEndgeratmit beschrankterRechenleistungundAn-bindungsbandbreitereichenkann.

Als Antwort aufdieseProblemstellungstelltdieseArbeit eineSoftware-Architekturzurverteilten3D Vi-sualisierungvor, dieDokumenteigenschaftenin offenen,verteiltenUmgebungenunterstutztundeinKomple-xitats-undSicherheitsmanagementermoglicht.DerStandderForschungaufdemGebietverteilterSoftware-Architekturenzur 3D Visualisierungwird zumeinendurchdie EntwicklungeinesneuenAnsatzeszur Un-terstutzungvon hybriden2D/3D Client-Szenenin verteilten,kooperativenArbeitsprozessenerweitert.ZumanderenwerdenneueMethodenzurVerteilungderVerarbeitungslast(Rendering),zurRegulierungderNetz-werklastund zur Sicherungvon 3D Dokumentenvorgestellt.Hierzu zahlt die EntwicklungeinesVerfah-renszum anwendungsunabhangigenZugriff auf verteilte3D Dokumente(Document-Request-Broker) unddesLevel-of-Information-Ansatzes,der eine Adaptivitat bezuglich der Ubertragungsrateund lokalen Be-rechnungslastmittels einerPerformanzmetrikermoglicht. Schließlichwird ein abgestuftesRechtekonzeptentworfen,dasdieDokumentsicherheitdurcheinkontrollierteVerteilungvonKopienmit angepaßtemInfor-mationsgehaltgewahrleistet.

FurdiePraxisergebensichausdenErgebnissenderArbeitneueMoglichkeitenfurArbeitsprozessein derdigitalenProduktentwicklung,die einebreiteSkalavon Informationenuberdie 3D Szenennutzenkonnen,an denengearbeitetwird. DieseSkalareicht von denbeschreibendenMetadatenbis hin zu denoriginalen3D Inhalten.Ein Szenariowie dasdesverteiltenDesign-Reviews von mehrerenbeteiligtenEntwicklernineinerstarkheterogenenUmgebungmit komplexenundzumTeil geschutzten3D Dokumentenwird damitinverbesserterFormunterstutzt,alsesin fruherenAnsatzen(Full-Replication-Ansatz) derFall war.

Inhaltsverzeichnis

1 Einf uhrung 11.1 Problemstellung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Losungsansatz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 ZielsetzungundForschungsbeitrag. . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Anwendungsszenario:Kooperative Planungskonferenzen . . . . . . . . . . . . . . 51.5 GliederungderArbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Grundbegriffe 72.1 DigitaleBibliotheken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 DigitaleDokumente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.1 AufbaudigitalerDokumente. . . . . . . . . . . . . . . . . . . . . . . . . 112.2.2 Eigenschaftenheterogenerundkomplexer Dokumente . . . . . . . . . . . 122.2.3 DigitaleDokumentein relationalenDatenbanken . . . . . . . . . . . . . . 12

2.3 3D Dokumentein DigitalenBibliotheken . . . . . . . . . . . . . . . . . . . . . . 142.4 Sicherheitsaspektevondigitalen3D Dokumenten. . . . . . . . . . . . . . . . . . 17

2.4.1 VerfahrenzurBerucksichtigungderSicherheitsaspekte. . . . . . . . . . . 182.4.2 MangelderheutigenVerfahren. . . . . . . . . . . . . . . . . . . . . . . . 182.4.3 SkizzeeinesumfassendenManagement-Szenariosfur Schutzrechtevon3D

Dokumenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.4.4 ReprasentationundIntegrationvonSicherheitsinformationen . . . . . . . . 20

2.5 Arbeitenmit digitalenDokumentenin verteiltenUmgebungen . . . . . . . . . . . 23

3 Methoden 263.1 GeometrischeReprasentationenvonvirtuellen3D Objekten. . . . . . . . . . . . . 26

3.1.1 Polygonale3D Netze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.1.2 ParametrisierteKurvenundFlachen . . . . . . . . . . . . . . . . . . . . . 283.1.3 UnterteilungvonparametrisiertenKurvenundFlachen:SubdivisionSurfaces 293.1.4 Implizite Funktionsdarstellung: QuadricSurfaces. . . . . . . . . . . . . . 303.1.5 Erweiterungvon Objektreprasentationen . . . . . . . . . . . . . . . . . . 31

3.2 DigitaleBildsyntheseundinteraktive 3D Visualisierung. . . . . . . . . . . . . . . 323.2.1 Die Rendering-Pipeline. . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.2.2 LokaleBeleuchtungssimulation. . . . . . . . . . . . . . . . . . . . . . . 353.2.3 GlobaleBeleuchtungssimulation. . . . . . . . . . . . . . . . . . . . . . . 37

3.3 Verteilte,objekt-orientierteSysteme . . . . . . . . . . . . . . . . . . . . . . . . . 403.3.1 EigenschaftenverteilterSysteme. . . . . . . . . . . . . . . . . . . . . . . 403.3.2 VerwendungeinesObjektmodelles. . . . . . . . . . . . . . . . . . . . . . 42

iii

INHALTSVERZEICHNIS iv

3.3.3 Verteilungsplattformenfur objekt-basierteSysteme. . . . . . . . . . . . . 453.4 VerarbeitungvonBildinformationen . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.4.1 BilddatenCodierungdererstenundzweitenGeneration . . . . . . . . . . 503.4.2 NetzwerkubertragungvoncodiertenBilddaten . . . . . . . . . . . . . . . 54

4 Konzeptezur verteilten 3D Visualisierung 564.1 EineKlassifizierungverteilter3D Visualisierungsysteme. . . . . . . . . . . . . . 564.2 Komponentenverteilter3D Visualisierungsysteme. . . . . . . . . . . . . . . . . . 56

4.2.1 Verteilungvon3D Szenen . . . . . . . . . . . . . . . . . . . . . . . . . . 584.2.2 Interaktionmit verteiltenSzenengraphen. . . . . . . . . . . . . . . . . . 594.2.3 SynchronisationvonverteiltenSzenengraphen. . . . . . . . . . . . . . . 61

4.3 KonzeptezurVerteilungeinerVisualisierungs-Pipeline. . . . . . . . . . . . . . . 624.3.1 Lokale3D Visualisierungmit Datenreplikation . . . . . . . . . . . . . . . 634.3.2 Remote3D Visualisierungmit zentralerDatenhaltung . . . . . . . . . . . 64

4.4 Verteilte3D Visualisierungfur kooperative Anwendungen . . . . . . . . . . . . . 654.5 Kombinationvon lokalemundRemote-Renderingfur verteilte3D Szenen. . . . . 69

5 Verteilte Visualisierungmit Skalierbaren Szenen 725.1 Einfuhrung:DasPrinzipderSkalierbarenSzenen . . . . . . . . . . . . . . . . . . 725.2 Vergleichmit vorhergehendenArbeiten . . . . . . . . . . . . . . . . . . . . . . . 745.3 DasKonzeptderSkalierbarenSzenenin derGesamtubersicht. . . . . . . . . . . . 755.4 DerLevel-of-InformationAnsatz . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.5 Modellierung von Navigations- und Interaktionsraummit einem Document-

Request-Broker-Ansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805.6 ManagementvonSicherheitsinformationen: Ein IPR-Filter . . . . . . . . . . . . . 825.7 DasKooperationsmodellderSkalierbarenSzenen. . . . . . . . . . . . . . . . . . 845.8 AdaptivesVerhaltendurchdynamischeKontrolledesLoI-Reglers . . . . . . . . . 85

5.8.1 LeistungsmessungundRegelgroßen . . . . . . . . . . . . . . . . . . . . . 875.8.2 FestlegungeinerMetrik zurLeistungsmessung. . . . . . . . . . . . . . . 89

5.9 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

6 Entwurf der verteilten Software-Architektur 936.1 Einfuhrung:DerEntwicklungsprozeß. . . . . . . . . . . . . . . . . . . . . . . . 936.2 Anforderungsanalyse: KomponentenundihreModellierung . . . . . . . . . . . . 956.3 Designmodell:VerteilterEntwurf fur dasKonzeptderskalierbarenSzenen. . . . . 97

6.3.1 Die Visualisierungskomponenten . . . . . . . . . . . . . . . . . . . . . . 986.3.2 ModellierungeinesDocument-Request-Brokers . . . . . . . . . . . . . . . 996.3.3 Die Level-of-Information-Komponenten . . . . . . . . . . . . . . . . . . . 1036.3.4 Die KomponentenderBilddatenschicht. . . . . . . . . . . . . . . . . . . 107


7 Implementierung der Ar chitektur SCA3D 1107.1 Einfuhrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1107.2 VerwendungvonSoftware-undHardware-Werkzeugen. . . . . . . . . . . . . . . 110

7.2.1 3D Visualisierung:DasRadiance-SystemunddieOpenInventor-Bibliothek 1117.2.2 Hardware-Komponenten. . . . . . . . . . . . . . . . . . . . . . . . . . . 114

7.3 RealisierungdeserstenPrototypen:Remote-RenderinguberMPEG-4Videostrome 115

INHALTSVERZEICHNIS v

7.4 ImplementierungderSCA3D-Architekturfur denLevel-of-Information-Ansatz. . 1167.4.1 DasSchichtenmodellderSCA3D-Architektur. . . . . . . . . . . . . . . . 1167.4.2 UmsetzungundAnwendungin einervernetztenRechnerumgebung . . . . 121


8 Adaptive Visualisierungin Offenen Informationsraumen 1238.1 Einfuhrung:Anforderungenin offenenInformationsraumen. . . . . . . . . . . . . 1238.2 EntwicklungeinesAnwendungsszenariosundeinerTestumgebung . . . . . . . . . 1248.3 Komplexitats-Managementfur verteilte3D Dokumente. . . . . . . . . . . . . . . 127

8.3.1 Klassifizierungvon3D DokumentenbezuglichdesInformationsgehaltes. 1278.3.2 Einordnungvon Client-Anwendungenin Leistungsklassen. . . . . . . . . 1298.3.3 RealisierungmittelsderOpenInventor-KlasseSoComplexity . . . . . . . . 1298.3.4 PraktischeErgebnissezumadaptivenVerhaltenvonSCA3D . . . . . . . . 133

8.4 Sicherheits-ManagementdurchvariablenInformationsgehaltvon Objektreprasen-tationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1398.4.1 Document-Distribution-Classes fur 3D Dokumente. . . . . . . . . . . . . 1398.4.2 FestlegungvonBenutzertypen. . . . . . . . . . . . . . . . . . . . . . . . 1408.4.3 VergleichvonDokumentinformationenundBenutzerinformationen. . . . 1408.4.4 BereitstellunggeeigneterMethodenmit demDocument-Request-Broker . . 1428.4.5 PraktischeErgebnissebeiderAnwendungeinesabgestuftenRechtekonzepts143


9 KooperativesArbeiten innerhalb der SCA3DAr chitektur 1469.1 Einfuhrung:AnforderungenandieVisualisierungsumgebung beiderKooperation. 1469.2 Kooperative SzenarienunterVerwendungdesSCA3DKonzeptes. . . . . . . . . . 147

9.2.1 NutzungvonNavigations-undInteraktionsbereichen . . . . . . . . . . . . 1489.2.2 UnterstutzungderKooperationdurchInformationsvisualisierung . . . . . . 151

9.3 ZugriffstransparenzundSynchronisationvon3D Objekten . . . . . . . . . . . . . 1539.3.1 Synchrone Interaktion mit 3D Objekten durch Transform- und

Manipulator-Knoten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1539.3.2 Zugriff aufObjektparameteruberdynamischerzeugteAufrufschnittstellen 1559.3.3 AnpassungderObjektreprasentationen in denInteraktionsraumen . . . . . 159

9.4 Ergebnisse:Kooperative Arbeitsprozessemit demLevel-of-Information-Ansatzes . 1609.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

10 Zusammenfassungund Ausblick 16510.1 ErreichteZieleundSchlußfolgerungen. . . . . . . . . . . . . . . . . . . . . . . . 16510.2 WeiterfuhrendeArbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Abbildungsverzeichnis

1.1 Reprasentationenvon 3D Objektenmit verschiedenemLevel-of-Information. . . . 31.2 SystemubersichtdesvorgeschlagenenLosungsansatzes.. . . . . . . . . . . . . . . 41.3 DasSchieberegler-Prinzip in einerverteiltenVisualisierungsumgebung. . . . . . . 51.4 ArbeitsprozessenutzendiegesamteInformationsskalafur 3D Dokumente.. . . . . 6

2.1 SkizzeeinesverteiltenDL-Systemsmit LieferantenundBenutzern. . . . . . . . . 82.2 BeispieldokumentFlughafengebaude.Quelleder Einzelbilderund Modelle: ETH

Zurich,FachbereichArchitektur. . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 Trennungvon StrukturundInhaltvon DL Dokumenten. . . . . . . . . . . . . . . 112.4 Entity-Relationship-Diagrammfur DL Dokumentein relationalenDatenbanken. . . 132.5 Szenengraph-Strukturmit Pfadinformationin OpenInventor. . . . . . . . . . . . . 152.6 SchichteneinesManagement-Szenarios.. . . . . . . . . . . . . . . . . . . . . . . 192.7 Objektmodellzur Integration,EvaluationundExtraktionvonSicherheitinformatio-

nenfur digitaleDokumente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.8 SkizzierungeinerDL-Umgebungmit denkritischenAspekten . . . . . . . . . . . 25

3.1 Beschreibungsformenfur polygonale3D Netze. . . . . . . . . . . . . . . . . . . . 273.2 ModellierungeinesObjektesdurchUnterteilungnachdemLoop-Schema(Abbil-

dungaus[Gro98]). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3 ErweiterteRepasentationenzur Erhaltungvon Objekteigenschaftenzwischenzwei

Visualisierungs-Pipelines.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.4 Visualisierungs-undAktions-PipelinebeiderinteraktivenVisualisierung. . . . . . 333.5 AllgemeinesVisualisierungsmodellnachHaberundMcNabb[HM90]. . . . . . . . 333.6 Rendering-Pipeline.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.7 LokaleBeleuchtungssimulationmit spekularemAnteil. . . . . . . . . . . . . . . . 363.8 GlobaleBeleuchtungssimulationdurchrekursivesRay-Tracing.. . . . . . . . . . . 383.9 AufbaueinesverteiltenSystemsmit Austauschvon Nachrichten.. . . . . . . . . . 413.10 SchematischeDarstellungeinesObjektesmit ZustandundVerhalten.. . . . . . . . 443.11 OMA-Referenz-Architektur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.12 Aufruf vonMethodenverteilterObjektemit CORBA. . . . . . . . . . . . . . . . . 473.13 CORBA Komponenten.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.14 GegenuberstellungvonDatenratenundNetzleistungfur digitaleVideoformate. . . 503.15 Message-Extraktionund-CodierungbeidervisuellenDatenkompression. . . . . . 513.16 SchemaeinesMPEG-1Videocoders.. . . . . . . . . . . . . . . . . . . . . . . . . 523.17 StruktureinesMPEG-4Bitstroms. . . . . . . . . . . . . . . . . . . . . . . . . . . 533.18 DecodierungeinesMPEG-4-Bitstroms:RekompositionundRendering. . . . . . . 543.19 NetzwerkubertragungvoncodiertenBilddaten. . . . . . . . . . . . . . . . . . . . 55

vi

ABBILDUNGSVERZEICHNIS vii

4.1 SymbolischeBeschreibung von KomponenteneinesverteiltenVisualisierungssy-stemsmit lokalem3D Renderingfur einenBenutzer. . . . . . . . . . . . . . . . . 58

4.2 Interaktionmit einementferntenSzenengraphenin einemverteiltenSystem.. . . . 604.3 VollstandigeSynchronisationzweier verteilter Szenengraphenuber Middleware.

Aktiver Client (rechts)undsynchronisierterClient (links). . . . . . . . . . . . . . 624.4 Remote3D Visualisierungmit einerRendering-Pipeline.. . . . . . . . . . . . . . 644.5 Multi-User-Visualisierung: Loka-

le Visualisierung(links) und Remote-Visualisierungmit individueller Navigation(rechts). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.6 Multi-User Visualisierung:Remote-Visualisierungmit vollstandigerSynchronisa-tion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.7 Kombinationvon lokalerundRemote-Visualisierungfur einenBenutzer. . . . . . . 694.8 KombiniertesSCA3D-Konzeptmit dynamischerVerteilungderOriginalszene. . . 70

5.1 DasKonzeptderSkalierbarenSzenen.. . . . . . . . . . . . . . . . . . . . . . . . 735.2 GesamtubersichtdesKonzeptesderSkalierbarenSzenen . . . . . . . . . . . . . . 765.3 Objektreprasentationenvon 3D Objektenmit variablemGehaltanInformation. . . 785.4 Reprasentationeines3D Dokumentesauf Client-Seiteals Bildobjekt (links), als

Kombinationaus3D- undBildobjektenundals3D Gesamtszene.. . . . . . . . . . 805.5 KonzepteinerDocument-Request-Broker Architekturfur objekt-orientierteDoku-

mentmodelle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.6 Sicherheitsmanagementim KonzeptderSkalierbarenSzenen.. . . . . . . . . . . . 825.7 DasKooperationsmodellderSkalierbarenSzenenmit demMethodenkern. . . . . . 845.8 KlassifizierungvonClient-AnwendungenundZuordnungvonObjektreprasentatio-

nenmit geeignetemLevel-of-Information. . . . . . . . . . . . . . . . . . . . . . . 855.9 DynamischeKontrolleder Schiebereglerpositionenin einerverteiltenMehrbenut-

zerumgebung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.10 Regel-undMeßgroßenin derSCA3DArchitektur. . . . . . . . . . . . . . . . . . 875.11 BestimmungderoptimalenFrameratendesClientsunddesServers. . . . . . . . . 895.12 ErmittlungderLeistungunddesVerhaltenseinesClient-Rechnersbei variierender

GeometriebelastungundVerbindungsbandbreite. . . . . . . . . . . . . . . . . . . 905.13 VerlaufderGewichtungsfaktoren�� und � � . . . . . . . . . . . . . . . . . . . . . . 91

6.1 Iterativer Entwurfsprozeßfur Software-Systeme. . . . . . . . . . . . . . . . . . . 946.2 ErweitertesUse-Case-Diagrammfur SCA3D. . . . . . . . . . . . . . . . . . . . . 966.3 SichtderBenutzerschnittstellen3DVis-GUI (links) undPanel-GUI(rechts). . . . . 976.4 Package-DiagrammderSCA3DArchitektur. . . . . . . . . . . . . . . . . . . . . . 986.5 Komponentender3D Visualisierungsschicht.. . . . . . . . . . . . . . . . . . . . 996.6 SchematischerAufbaudesDocument-Request-Brokers. . . . . . . . . . . . . . . . 996.7 Sequenzdiagrammfur die Aktivierung einesObjektesund die Erzeugungeines

Interface-Objektes.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006.8 AufbaueinerSCA3D-Nachricht.. . . . . . . . . . . . . . . . . . . . . . . . . . . 1026.9 Sequenzdiagrammfur denAufruf einesRemote-Document-Calls.. . . . . . . . . 1036.10 SequenzdiagrammderAblaufebeimPerformanztesteinerClient-Anwendung.. . . 1056.11 IntegrationdurchVerwendungeinesAttributknotensunddurchKonstruktioneines

Interface-Objektes.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1066.12 AufbauderBilddatenschichtderSCA3D-Architektur. . . . . . . . . . . . . . . . . 108

ABBILDUNGSVERZEICHNIS viii

6.13 SequenzdiagrammdesVerbindungsaufbausunddesBilddatenaustausches. . . . . 108

7.1 Die OpenInventor-Architektur nach[Wer98] . . . . . . . . . . . . . . . . . . . . . 1127.2 HierarchiederSoAction-KlassenvonOpenInventor . . . . . . . . . . . . . . . . . 1137.3 BeschreibungderHardwarederEntwicklungsumgebung. . . . . . . . . . . . . . . 1147.4 Zugriff auf server-seitige3D ObjekteuberdieKennungvonVideoobjekten . . . . 1157.5 AufbauderSCA3D-ArchitekturdargestelltalsSchichtenmodell.. . . . . . . . . . 1177.6 Die GUI-Oberflacheder WWW-Schicht.Quelle der Einzelbilder und Modelle:

ETH Zurich,FachbereichArchitektur. . . . . . . . . . . . . . . . . . . . . . . . . 1187.7 Die graphischeOberflache3DVis-GUI derSCA3DClient-Anwendung.Quelledes

CAD-Modells:ETH Zurich,FachbereichArchitektur. . . . . . . . . . . . . . . . . 1197.8 AufbauundEinsatzderDokumentkontrollschicht. . . . . . . . . . . . . . . . . . . 1207.9 KomponentendiagrammderSoftware-ArchitekturSCA3D. . . . . . . . . . . . . . 1217.10 Deployment-DiagrammderSoftware-ArchitekturSCA3Din derEntwicklungsum-

gebung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

8.1 Visualisierungin einemoffenenInformationsraum.. . . . . . . . . . . . . . . . . 1238.2 AuswahleinergeeignetenReprasentationsform.. . . . . . . . . . . . . . . . . . . 1288.3 EinteilungdesLFR-RFR-Diagrammsin Leistungsklassen.. . . . . . . . . . . . . 1308.4 ZusammenhangzwischenComplexity-Wert und Dreiecksanzahlfur verschiedene

OpenInventor-Objekte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1318.5 Quelltext derMethodenzumAbtasteneines3D Objektes.. . . . . . . . . . . . . . 1328.6 ReprasentationeneinerNURBS-Flacheals3D Netzmit steigederKomplexitat und

alsOriginal.QuelledesModells:Teapotim OriginalvonM.Newell. . . . . . . . . 1338.7 Verwendungdes Complexity-Werteszur Einteilung der LoI-Skala ( ��

Dreiecke proFlacheneinheit).. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1348.8 KlassifizierungderTestrechner. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1358.9 BestimmungeinesstabilenBereichesfur die Leistungsbewertung von Client 1

(Win-Notebook). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1368.10 Leistungsbewertungfur Client2 (Unix-Rechner). . . . . . . . . . . . . . . . . . . 1378.11 Leistungsbewertungfur Client3 (Win-PC). . . . . . . . . . . . . . . . . . . . . . 1378.12 BestimmungderSchranken �� und �� undderentsprechendenLoI-Ubergange. 1388.13 ErlaubteUbergangefur verschiedeneDocument-Distribution-Classes. . . . . . . . 1398.14 Benutzertypenundihre maximalenZugriffsrechte. . . . . . . . . . . . . . . . . . 1408.15 VergleichvonBenutzerinformationundDokumentinformation.. . . . . . . . . . . 1418.16 Auswahlvon Objektreprasentationen mit Sicherheitsmanagement.. . . . . . . . . 1438.17 VerfugbareObjektreprasentationen: Bounding-Box-Information, 3D Netzoderori-

ginaleNURBS-Flache. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

9.1 KooperativesSzenarioinnerhalbderSCA3D-Architektur. . . . . . . . . . . . . . . 1499.2 SynchronisationderKamerasunddesvisuellenFeedbacks.. . . . . . . . . . . . . 1509.3 Avatare(grunerundroterQuader)von zwei Benutzerngesehenvon einemdritten

Teilnehmer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1529.4 Synchronisierungvon Objekten mittels der OIV-Klassen SoTransform und

SoTransformerManip. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1549.5 VerwaltungderReferenzenaufdieTransformeraufServer- undClient-Seite. . . . 1559.6 Aufruf entfernterMethodenuberdynamischerzeugteSchnittstellen.. . . . . . . . 156

ABBILDUNGSVERZEICHNIS ix

9.7 AusschnittausdemIDL-InterfacezumAufruf vonRemote-Document-Calls.. . . 1589.8 Ausgangsdokumentefur diekooperative 3D Konferenz.. . . . . . . . . . . . . . . 1629.9 ScreenshoteinerSCA3D-Client-AnwendungenwahrenddesArbeitsprozesses.. . 1629.10 ScreenshotderClient-AnwendungendesanderenTeilnehmersnachFertigstellung

desDokumentes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Tabellenverzeichnis

2.1 GebrauchlicheReprasentationsformenvon Sicherheitsinformationen. . . . . . . . . 22

3.1 Vor- undNachteileverteilterSystemegegenuberzentralenSystemen. . . . . . . . 41

4.1 KlassifizierungvonverteiltenVisualisierungssystemen.. . . . . . . . . . . . . . . 57

x

“ Wemustplanfor freedom,andnotonly for security, if for noother

reasonthanthatonly freedomcanmake securitysecure.“

Karl R. Popper, “ TheOpenSocietyandIts Enemies“ , 1943

Danksagung

An ersterStellemochteich Herrn ProfessorDieter Fellnerfur die Betreuungder Arbeit unddie zahlreichenGesprachein Bonn und Braunschweigdanken, die zum Gelingender Arbeit undzur gemeinsamenEntwicklungvieler wichtiger IdeenderArbeit gefuhrt haben.Ebenfalls dankenmochteich Herrn ProfessorMartin Reiser, der als Leiter desInstitutsfur Medienkommunikationdie Anfertigungder Arbeit ermoglicht und in vieler Hinsicht dasWeiterkommenunterstutzt hat.Als sehrengagiertenZweitgutachterhabeich Herrn ProfessorHans-Jurgen Appelrathvom Ol-denburger Forschungs-und Entwicklungsinstitutfur Informatik-Werkzeugeund -SystemeOFFISkennengelernt,demich hiermit meinenDank aussprechenmochte.Der BetreuunginnerhalbderArbeitsgruppeValue-added-Solutions(VaS)am IMK durchHerrn Dr. ManfredBogenist zu ver-danken,daßich auf demgesamtenWeg von dererstenIdeebis zur fertigenArbeit immerwiederdasZiel im Auge behaltenhabe.Danke fur die gutenGesprache,Kommentareund Anregungenim RahmenderArbeit unddie offeneArbeitsatmosphare,Manfred.Die ZusammenarbeitundDis-kussiondesArbeitsthemasmit HerrnDr.-Ing. JoachimKohlerhabenmir viele neueIdeenunddienotigeUnterstutzungfur die letztePhasederArbeit gegeben.HerrnDipl.-Phys.PeterWunderlingmochteich alsArbeitsgruppenleiterdesneuenKompetenzzentrumsNetMediaamFraunhofer-IMKfur seineHilfe undUnterstutzungdanken.

Fur die sehrguteZusammenarbeitals Doktorandenin NetMediaund fur dasgeduldigeKor-rekturlesendesfertigenTextesmochteich besondersGundulaDorriesdanken. Die mittaglichenDiskussionenbei exotischenTeesortenwarenfur meineArbeit sehranregend.In denverschiede-nenPhasender Arbeit habenmir viele weitereKollegengeholfen:AndreasKarajanniswar stetsein kompetenterAnsprechpartnerim BereichWeb-TechnologieundDatenbanken,LotharZier hatmir im weiten Gebietder Netzwerke zahlreicheTipps gegebenund Martha Larsonhat bei derFormulierungenglischerPapieremit nutzlichenHinweisengeholfen.DurchdenEinklangbei dergemeinsamenNutzungeinesBurosundzeitweilig ihresMacshatInke Kolb bei derFertigstellungderArbeit mitgewirkt. Allen anderenMitarbeiternderArbeitsgruppenVaSundNetMediamochteich nocheinmalbesondersfur die Hilfe in fachlichenFragen,die guteZusammenarbeitund denSpaßbeivielenFreizeitendanken.

SchließlichgehtmeinDankanmeineElternundmeineSchwesterndafur, daßsiemeineArbeitstetsunterstutzt undmir auchin allem,wasdaruberhinausgeht,immergeholfenhaben.

Kapitel 1

Einf uhrung

Mit demAufkommenglobalzuganglicherInformationssysteme,wie z.B.digitalenBibliothekenimInternet,entstehenneueArbeitsprozesse(z.B.virtuelleProduktdefinition),dieeineWeiterentwick-lung fortschrittlicherTechniken fur Retrieval, Darstellungund Interaktiondigitaler Objektenotigmachen.Die wachsendeVerfugbarkeit und Komplexitat von digitalenDokumenten,die ebenfallseinenSchutzvon Originaldatenerforderlichmachen,mussenzudemEinflußauf die EntwicklungmodernerAnwendungsarchitekturen nehmen.Als spezielleAnforderungan Informationssystemewird das interaktive Arbeiten mit 3D Szenenvon zahlreichenAnwendungsbereichenwie demComputer-Supported-Cooperative-Design, derMedizin oderdemComputer-basedTraininggefor-dert.Fur die UntersuchungenundEntwicklungendieserArbeit werdendie Eigenschaftenvon di-gitalenDokumentenfur dasverteilteArbeitenmit 3D Szenengenutzt,umeinenflexiblenUmgangmit komplexenundgeschutzten3D Dokumentenin offenenInformationsraumenzuermoglichen.

Mit dem Ziel, eine flexible und offene Umgebung fur dasRetrieval, die VisualisierungundManipulationvon 3D Dokumentenzu schaffen, wird die verteilteSoftware-ArchitekturSCA3Dals erweiterbaresMehrbenutzersystementwickelt. Ein offenerInformationsraum,in demsich dieAnwenderwahrendeinesArbeitsprozessesvirtuell bewegen,umfaßt hier mehrereInformations-Server mit Dokumentdatenbanken, einepotentiellgroßeAnzahlvon Benutzernmit verschiedenenEndgeratenundKommunikationsnetzezwischendiesenKomponenten.Die HauptmerkmaleeinesoffenenInformationsraumessinddieeinheitlichenBedingungenfur dasArbeitenmit digitalenOb-jekten,die allenBenutzerntrotz unterschiedlicherUmgebungsbedingungen bereitgestelltwerden,unddieErweiterbarkeit durchSchnittstellenzuweiterenInformationsraumen.Um eineindividuelleSkalierungderlokal verfugbarenInformationsmengefur jedenBenutzerzuermoglichen,wurdeeinLevel-of-InformationAnsatzentworfenund in die Software-Architekturintegriert. Die gewahltenBasistechnologienzur Entwicklungverteilterobjekt-orientierterSoftware-Architekturenermogli-chendurchihre Verbreitungund Interoperabilitat einenweitenEinsatzbereichin der Praxis.An-wendungenzuminhalts-basiertenRetrieval in 3D Web-Datenbanken konnenmit derentwickeltenSoftware-ArchitekturSCA3Dgenausorealisiertwerden,wie kooperative 3D Designumgebungenmit AnforderungenausderIndustriepraxis.

1.1 Problemstellung

Bei derverteilteninteraktiven Visualisierungvon 3D Szenenwerdenheuteim wesentlichenzweiAnsatzeverfolgt,namlicheinerseitsdaslokaleRenderingvon repliziertenDaten[HSF99]undan-dererseitseinRemote-Rendering-Ansatz[ESE99],[HJT98] mit zentralverwalteten3D Geometrie-

1

KAPITEL 1. EINFUHRUNG 2

daten.Die DatenundProzessewerdendabeizwischendenSystemkomponentenauf unterschiedli-cheWeiseverteilt,wodurchdieBelastungdesverbindendenNetzesundderbeteiligtenRechnerzuEngpassenin derUbertragungundVerarbeitungfuhrenkann.

DaeindirektesFeedbackbeider3D Visualisierungsehrentscheidendfur dieBenutzbarkeit ei-nesSystemsist, wird in vielenAnwendungenderlokaleRendering-Ansatzeingesetzt,d.h.die 3DDokumentewerdenalsKopiezumBenutzerubertragenunddort weiterverarbeitet.DenVorteilen,die dieserAnsatzbietet,stehenaberauchgravierendeNachteilegegenuber, die sehrentscheidendfur heutigeundzukunftigeSystemeseinkonnen.Der wesentlicheNachteillokalerVisualisierungin verteiltenAnwendungenbestehtdarin,daßfur geschutzteDatenkeinedirektenMoglichkeitenbestehen,um die Originaldatenwirksamzu schutzen.Da zur Visualisierungmit hoherQualitat inderRegel die Originaldatennotig sind,mußimmereinevollstandigeKopiedieserDatenuberdasNetzverteilt werden.Kennzeichungmit digitalenWasserzeichenundSignaturen,wie esauchzurSicherungvon digitalenBilddatenverwendetwird, ist beimheutigenStandderTechnikals nichtimmer voll ausreichenderSchutzvon 3D Datenanzusehen,da eine nachtraglicheManipulationdieserZusatzdatenrelativ leicht moglich ist. Ein weitererNachteillokalerVisualisierungsansatzeist, daßfur sehrkomplexe 3D Dokumentedie UbertragungselbstzumProblemwird, dadie Netz-leistungund eventuell die lokal bereitgestellteVerarbeitungsleistungdesBenutzerrechnersnichtausreichendist. In diesemFall gibt esheutekeineMoglichkeit, die tatsachlichamClient benotig-te Mengean Informationfur beliebigeReprasentationsformenvon 3D Modellen (parametrischeModelleund polygonaleNetze)stufenweisezu regulieren.Level-of-Detail-Ansatzefunktionierenbishernur fur 3D-Netze,konnenalsoerstnachdemTesselierungsschritteingesetztwerden.FurparametrischeModelleundangereichertezweidimensionalenInformation(Bildobjekte,Bounding-Boxes,etc.),die eineNutzungder vollstandigeSkalavon Reprasentationenvon 3D ObjekteninVisualisierungsumgebungen ermoglichen,sind bisherkeineUntersuchungenmit der ZielsetzungeinerdynamischenKontrolledesInformationsgehaltsvorgenommenworden.

Eine alternative Losungzum Schutzder Eigentumsrechteund zur minimalenBelastungdesNetzesundderClient-Anwendungmit Geometriedatenist derRemote-Rendering-Ansatz,bei demdieDatenamServerberechnetwerdenundamClientalsBildinformationvisualisiertwerden.Die-serAnsatzhat aberdenNachteil,dassimmer einemehroderwenigergroßeVerzogerungin deninteraktivenArbeitsprozesseingefuhrtwird. Hierfur ist dieVerzogerungdurchdieNetzubertragungderBilddatenverantwortlich,aberauchdieserver-seitigeBilderzeugunghineinunddieBildanzeigeaufClient-SeiteverursachenVerzogerungen.

Die beidenwichtigstenProbleme,die bei derEntwicklungeinerverteiltenVisualisierungsum-gebung zu losensind,ergebensich alsoausder Komplexitat der zu bearbeitenden3D DatenunddenhohenSicherheitsanforderungen, die zumSchutzderOriginaldatengestelltwerden.Losungs-ansatzefur dieseProblemesolltenMethodenfur ein effektivesKomplexitats-undSicherheitsma-nagementfur 3D Dokumentein heterogenenNetzwerkumgebungenbereitstellen.

1.2 Losungsansatz

Der in dieserArbeit vorgestellteAnsatzkombiniertdie MethodendeslokalenRenderingsunddesRemote-Renderingsin verteiltenVisualisierungsumgebungen, um die VorteilederbeidenAnsatzezu nutzenund neueTechniken zur Losungder angesprochenenProblemezu entwickeln. Dabeiwird der Begriff desLevel-of-Informationfur ein 3D Objekt eingefuhrt, der denverfugbarenIn-formationsgehaltfur ein 3D Objekt auf der Skalazwischenexakter 3D Information und reinerBildinformationbeschreibt.


Abbildung1.1:Reprasentationenvon3D Objektenmit verschiedenemLevel-of-Information.

DurchdenLevel-of-Information-Ansatzist esalsomoglich,daßkomplexe Informationen(hier3D Dokumente)in verteiltenUmgebungennicht von vornhereinvollstandigzum Benutzeruber-tragenwerdenmussen,um mit ihneninteraktiv arbeitenzu konnen.Vielmehrwird hier ein Ansatzverfolgt,bei demnur die fur denaktuellenGradanInteraktionnotigeInformationsmengeubertra-genwird. Fur 3D Dokumentebedeutetdies,daßeineschrittweiseSteigerungderInformationsmen-geamClient von reinerBildinformation,uberBildinformationmit Objektkontur, uberTextur plusKonturplusBounding-Box,bishin zurvollstandigen3D Geometrierealisiertwerdenkann.In Ab-bildung1.1 ist die ErzeugungverschiedenerReprasentationenvon 3D Objektenmit variierendemLevel-of-InformationentlangeinerVisualisierungs-Pipeline gezeigt.

Die skizierteLosungderbeidengenanntenProblemesetztvoraus,daßdie StrukturundderIn-haltder3DDokumenteaufverschiedenenReprasentationsebenenin demverteiltenSystemzugang-lich gemachtwerden.Zu diesemZweckbietetsichdie VerwendungSzenengraph-basierter Visua-lisierungsmethodenan. Allgemeinerwird im weiterender Begriff desobjekt-orientiertenDoku-mentmodellesverwendet,derdemSzenengraphansatzbei der3D Visualisierungentsprichtundeserlaubt,3D Szenenals3D Dokumenteanzusehen.DerhiervorgestellteLosungsansatzderSkalier-barenSzenen, derauf einemobjekt-orientiertenDokumentmodellaufbaut,arbeitetmit einemNa-vigationsbereichaufServer-Seite(S)undeinemInteraktionsbereichaufClient-Seite(C), zwischendenensichein IPRFilter (IntellectualPropertyRights) zumVerteilungsmanagementvongeschutz-ten 3D Objektenbefindet(sieheAbbildung 1.2). Durch Verwendungvon Remote-Visualisierungim NavigationsbereichundlokalerVisualisierungim Interaktionsbereich kannaufObjekteaufver-schiedenArten zugegriffen werden,je nachdemin welchemBereichsiesichaktuellbefinden.EinBenutzererhalt alsodie Moglichkeit, von der reinenNavigation in einervirtuellenSzeneschritt-weisezueinerlokalenInteraktionzugelangen.

1.3 Zielsetzungund Forschungsbeitrag

In der vorliegendenArbeit wird ein Konzeptund die Entwicklung einer verteilten Software-Architekturvorgestellt,die die AnsatzedesRemote-RenderingunddeslokalenRenderingkombi-niert, um denLevel-of-Information-Ansatzzu realisieren.DieseSoftware-Architekturerlaubtdeninteraktiven Zugriff auf verteilte Objekteeines3D Dokumentesbei der Visualisierunguber 2DInformation (Pixel, Remote-Rendering)bzw. uber die 3D Information (Geometriedaten,lokalesRendering).ZwischendiesenbeidenBegrenzungspunktenwerdenmoglichstkontinuierlicheZwi-schenschrittedesinteraktivenZugriffs ermoglicht.DieserLosungsansatzwird hiermit einemSchie-beregler verglichen,derzwischendenbeidenextremenReprasentationsformeneinesObjektesals


Abbildung1.2:SystemubersichtdesvorgeschlagenenLosungsansatzes.

3D Geometriedatenbzw. als2D Bilddatenkontinuierlichreguliert werdenkann.In Abbildung1.3ist dasSchieberegler-Prinzip innerhalbeinerverteiltenVisualisierungsumgebung veranschaulicht.DurchZugriff auf die Strukturdes3D DokumentesamServer konneneinzelneObjekteselektiertundschrittweiseausdemHintergrundherausgelost werden,womit eineschrittweiseUbertragungder Objektinformationzum Client verbundenist. Die Beschrankungender PositionendesSchie-bereglersdurchdie Randbedingungender Umgebung und die dynamischeKontrolleder PositiondurcheinegeeigneteSteuerungsollenin derArbeit untersuchtwerden.

Auf konzeptzionellerEbenetragtdieArbeit mit demZusammenbringenderBegriffe desdigita-lenDokumentesundder3D SzenezumForschungsbereichdermultimedialenInformationssystemebei,indemdievorhandenenMethodenzurVerarbeitungvondigitalenDokumentenundvon3D Da-tenkombiniertundfur denzukunftigenEinsatzin digitalenBibliothekenuntersuchtwerden.Insbe-sonderewird dasPotentialdieser3D Dokumentefur denUmgangmit komplexer undgeschutzterInformationin denobenbeschriebenenoffenenInformationsraumenuntersucht.Auf technischerEbenewerdendafur dieKombinationsmoglichkeitenverschiedenerVisualisierungskonzepte unter-suchtundeineSoftware-Architekturentwickelt, dieeinedynamischeIntegrationvon lokalemRen-deringundRemote-Renderingin einerverteiltenMehrbenutzeranwendungermoglicht.Ein eigenerSteuerungsmechanismuszur adaptiven Kontrolle desInformationsgehaltesauf Client-Seitewirdentwickelt und in praktischenTestsausgewertet.Hierfur wird einePerformanzmetrikeingefuhrt,die zur SteuerungdesLevel-of-Information-Parametersin derverteiltenVisualisierungsumgebungverwendetwird. Schließlichwird eineKonzeptfur denZugriff aufbeliebige3D Dokumentein ver-teiltenUmgebungenumgesetzt,dasder IdeeeinesMiddleware-Ansatzesfolgt und statischebzw.dynamischerzeugteSchnittstellenfur 3D Objekteverwendet.Damit wird eineZugriffs- undOrt-stransparenzbeimArbeitenmit 3D Dokumentenetabliert,d.h.ein Anwenderstellt keinenUnter-schiedbeimZugriff auf lokalebzw. entfernteObjektemehrfestundder tatsachlicheOrt (Server)einesentferntenObjektesmussnichtbekanntsein.Mit dynamischerzeugtenSchnittstelleninforma-tionenfur 3D Objektewird daruberhinauseineUnabhangigkeit von dereingesetztenAnwendungauf Client-Seitemoglich. Der Beitragder Arbeit zum aktuellenStandder Forschungliegt dahernebendenbeschriebenenPunktendertechnischenEbenebesondersauchin derEntwicklungsarbeiteineszukuntsorientiertenGesamtsystemsfur denflexiblen Umgangmit digitalenDokumenteninoffenenInformationsumgebungen.


Abbildung1.3:DasSchieberegler-Prinzip in einerverteiltenVisualisierungsumgebung.

1.4 Anwendungsszenario:KooperativePlanungskonferenzen

Ein vielversprechenderEinsatzbereichfur die entwickelten Konzepteist die virtuelle Produkt-definition, bei der digitale Prototypen(Digital Mock-Up in der Automobilindustrie)helfen,denProduktenstehungsprozess zu beschleunigenund die Kostenzu verringern.Der enormeAufwandbezuglich desInformationsaustausches zwischeneinemProduzentenund seinenzahlreichenZu-lieferern wahrendder Produktentwicklungwird mit den hier vorgestelltenTechniken effizientergestaltet.Gleichzeitigwerdendie hohenSicherheitsanforderungen bei derVerarbeitungwertvollerdigitalerProduktdaten(tradesecrets) berucksichtigtundfur denEinsatzin derPraxishandhabbargemacht.

Als Anwendungsszenariofur dieArbeit werdenkooperative Planugskonferenzenin dervirtuel-len Produktdefinitiongewahlt,bei denenmehrereAnwenderalsMitarbeiterderbeteiligtenFirmengemeinsammit 3D Dokumentenarbeiten.Hierei werdenAnfragenanverteilteDatenbanksystemegestellt,um ein Retrieval auf denDokumentbstandendurchzufuhren,ausgewahlte3D Dokumentewerdenin derverteiltenUmgebungvisualisiert,wobeiauchManipulationenander3D Daten(z.B.fur dieModellierungneuerProdukte)vorgenommenwerden,undschließlichwerdenneuentstande-ne3D Dokumentein diedigitaleBibliothek integriert. Im BeispieldervirtuellenProduktdefinitionarbeitenKonstrukteureeinesAutomobilherstellersgemeinsammit denMitarbeiternvon Zuliefe-rerfirmenan der Integration von Einzelkomponentenin einendigitalen PrototypeneinesneuenFahrzeugs.Hierbei werdendie 3D Daten,die sich in verschiedenenDatenbanken befinden,denBauteilendesPrototypenmit Hilfe einerMaterialliste(bill of material) zugeordnet.Bishermussendafur alle Originaldatenvom Zulieferer vor Beginn desPlanungsprozesseszum Produktherstel-ler ubertragenwerden,wobei einserseitsenormeDatenubertragungsmengen erzeugtwerdenundandererseitskritischeProduktdateneinesZuliefersauf Vertrauensbasis,die eventuell vertraglichabgesichertist, weitergegebenwerdenmussen.Die unterschiedlichenverfugbarenNetz-undRech-nerressourcenderTeilnehmereinersolchenKonferenz,dieKomplexitat derbearbeiteten3D Datenundschließlichauchdie bestehendenAnforderungenandenSchutzderDatenlassendenEinsatzneuerkombinierterAnsatzezurverteilten3D Visualisierungsinvoll erscheinen.Fur diePraxiswer-denauf dieseWeiseArbeitsprozessein vernetztenArbeitsumgebungenmoglich, die die gseamteInformationsskalavon beschreibendenMetadatenbis zu denoriginalen3D Modellennutzen.InAbbildung1.4sindsolcheArbeitsprozessefur dievirtuelleProduktdefinitiondargestellt.


Abbildung1.4:ArbeitsprozessenutzendiegesamteInformationsskalafur 3D Dokumente.

1.5 Gliederung der Arbeit

DerweitereAufbauderArbeit ist wie folgt organisiert.In Kapitel2 werdendieGrundlagenzudenGebietenDigitaleBibliothekenund3D Dokumentediskutiert.Die Methoden,die fur dasVerstand-nis der Software-Architekturnotig sind, werdendannin Kapitel 3 vorgestellt.In Kapitel 4 wirdein Uberblick zum Standder Forschungauf demGebietder verteiltenVisualisierungsumgebun-gengegeben.Kapitel 5 stellt dasKonzeptder SkalierbarenSzenenzur verteiltenVisualisierungvon 3D Dokumentenvor und beschreibtdie darin enthaltenenneuenAnsatze.Der Entwurf derSoftware-ArchitekturSCA3Dwird in Kapitel 6 dargestelltund ihre Implementierungin Kapitel 7erlautert.DerSchwerpunktvonKapitel8 liegt dannaufderadaptivenVisualisierungin offenenIn-formationsraumen,wobeidasKomplexitats-undSicherheitsmanagementderSoftware-Architekturdiskutiertwird. Kapitel 9 beschreibtdie FunktionalitatenderSoftware-Architektur, die daskoope-rativeArbeitenmehrererBenutzermit 3D Dokumentenermoglichen.Schließlichwerdenin Kapitel10 die Ergebnisseder Arbeit zusammengefasstund ein Ausblick auf weiterfuhrendeForschungs-richtungengegeben.

Kapitel 2

Grundbegriffe

In diesemKapitel werdenGrundlagenzu denThemenDigitale Bibliotheken und digitale Doku-mentein verteiltenUmgebungenbeschrieben.Dabeigeht es um die VorstellungdesKonzeptesheterogenerdigitalerDokumentemit einerTrennungvon StrukturundInhalt, die Einfuhrungvon3D DokumentenalsUntergruppedigitalerDokumenteunddenSchutzvon Eigentumsrechtenvon3D Dokumenten.AußerdemwerdenBedingungenfur dasArbeitenmit digitalenDokumenteninverteiltenUmgebungenbeschrieben.

2.1 Digitale Bibliotheken

Der Begriff der Digitalen Bibliothek (Digital Library: DL) entstandim Zuge der rasantenEnt-wicklung vernetzterComputerumgebungenundderVerarbeitungvon Fachwissenin Form von di-gitalenDokumenten.Die Digitale Bibliothek ist eineUbertragungder IdeeundderKonzeptevonherkommlichenBibliotheken in denvirtuellenunddigitalenBereich.DurchdiesenUbergangvomgedrucktenBuchanrealenOrtenzu digitalenInformationenin verteilten,virtuellenUmgebungenwird der Begriff der Bibliothek aberauchstarkerweitertund fuhrt zu neuenMoglichkeiten undHerausforderungen.Die Digitale Bibliothek kannalsMetapherfur die elektronischenMarktedesWissensund fur die VersorgungeinersichentwickelndenWissensgesellschaftverstandenwerden[EF00].Hierdurchwird klar, wie bedeutendundweitreichenddieMoglichkeitendieserneuenEnt-wicklung in vielenBereichenderGesellschaftseinwerden.

DurchfolgendenZitatesollendie AufgabeneinerDigitalenBibliothek ausverschiedenenPer-spektivenbeschriebenwerden:� AusmarktwirtschaftlicherSichtergibt sichfolgendesBild derAufgaben[EF00]:

Esist dieAufgabeeinerdigitalenBibliothek,fur einenprivaten,akademischenundindustri-ellen Nutzerkreis ... effizienteDiensteanzubieten,die diesemhelfen,an das... in digitalenDokumentengespeicherteFachwissenzugelangen.� AuswissenschaftlicherSichtstellensichdieseAufgabensodar[SSNM97]:

Esist dieAufgabeeinerdigitalenBibliothek,dieAusnutzungdesglobalen,vernetztenInfor-mationsuniversumszuverbessern,mit klarer AusrichtungaufdieBedurfnissedesindividuel-lenNutzers undseinerTatigkeit.� HeutigeBibliotheksbenutzer, dievor allemdurchihrenUmgangmit herkommlichenBiblio-thekengepragtsind,wurdendieAufgabenvermutlichfolgendermaßenbeschreiben[EF00]:

7

KAPITEL 2. GRUNDBEGRIFFE 8

Esist dieprimare AufgabeeinerdigitalenBibliothek,diebekanntenProblemekonventionel-ler Bibliothekensystematisch zulosen.

Wie ausdiesenZitaten deutlichwird, werdenganzunterschiedlicheAnforderungenan eineDigitale Bibliothek gestellt.Die Vorstellungenausder jeweiligen Sicht erstrecken sich von einereinfachenVerbesserungderherkommlichenBibliothekendurcheindigitaleKomponentebishin zueinemsehrumfassendenSystemfur denZugriff globalverteiltenWissens.

Abbildung2.1:SkizzeeinesverteiltenDL-Systemsmit LieferantenundBenutzern.

In Abbildung 2.1 ist ein verteiltesSystemeiner Digitalen Bibliothek mit DL-Servern, meh-rerenBenutzern(privat, wissenschaftlich,industriell) und Lieferanten(Verlage,Fachgesellschaf-ten,Medienunternehmen,Nachrichtenagenturenetc.)dargestellt.Die BenutzerunddieLieferantensinduberverschiedeneWegemit demzentralenServer derBibliothekverbunden.Hier wird ange-nommen,daßsichdie BenutzerhauptsachlichuberdasInternetbzw. ein Intranetmit derDigitalenBibliothekverbinden,wahrendLieferantennebendiesenMoglichkeitenauchdigitaleLangzeitspei-cherverwenden,umDokumenteandieBibliothekzu liefern.Die HauptfunktionendesDL-Serverssind die Aufbereitung,Bereitstellungund Abrechnungvon Dokumentenund Diensten.Danebensollte aberauchdie Betreuungvon Benutzernund Lieferantenvon einemDL-Systemunterstutztwerden.Die Kernfunktionalitat, die Benutzernbereitgestelltwerdensollte, wird durchMoglich-keitenfur Suche,Zugriff, BestellungundAbrechnungvon digitalenDokumentenabgedeckt.Lie-ferantenwerdenvon demDL-Systemdarin unterstutzt, Inhalteeinzustellenund dieseLieferungabzurechnen.Wie ausAbbildung2.1 deutlichwird, mußein solchesSystemin derLagesein,mit


mehrerenverschiedenenLieferantenundeinerVielzahlvonBenutzernumgehenzukonnen.Außer-demsindin realenDigitalenBibliothekenauchSchnittstellenzuanderenDL-Systemengewunscht,sodaßStandards(wie z.B.Dublin-Core[WKL98] oderZ39.50[Lyn97]) zumAustauschvonDoku-mentenundMetainformationennotig sind.Durchdie Vernetzungvon DigitalenBibliothekenwirdeinSystemfur denZugriff globalverteiltenWissens,wie obenangedeutet,tatsachlichmoglich.

In dieserArbeit werdenvor allem folgendeAspekteuntersucht,die erstdurchdenUbergangzurDigitalenBibliothekermoglichtwerdenbzw. berucksichtigtwerdenmussen:� Als eine wichtige Erweiterungergibt sich die Moglichkeit der Kooperationmehrererver-

teilter Benutzermit Hilfe derdigitalenDokumentealsgemeinsamerWissensbasisfur ein zulosendesProblem.NeuentstandeneDokumentekonnenwiederumin dieBibliothekintegriertwerden,umdasenthalteneWissenin einemBereichzuerweitern.� DieseDokumentekonnenaußerdemheterogensein,d.h.sieumfassenInhaltemit verschie-denenDatentypenund mehrereDokumenttypen.Als Beispiel sei ein DokumentuberdenBaueinesFlughafengebaudesangenommen,dasnebendemText auchBilder, Video,Audiound3D Modelleenthalt. Die BenutzereinessolchenDokumentesmochtenmit denheteroge-nenInhaltenarbeiten,wobeigleichzeitigder strukturelleZusammenhangdesDokumentes,namlich die verschiedenenAspektedesGesamtgebaudes,erhaltenbleibensoll. Dies kannnur gewahrleistetwerden,wennderZugriff auf die DL-Dokumenteunddie lokal genutztenAnwendungennicht fur die verschiedenenDatentypengetrenntbehandeltwerdenmussen.Ein SchwerpunktderArbeit ist dasArbeitenmit DL-Dokumenten,die selbsteine3D Szenedarstellenodereine3D Datenkomponenteenthalten.DieseDL-Dokumentewerdenim fol-gendenals3D Dokumentebezeichnet.Die Komplexitat von 3D Dokumentenspielt bei derVisualisierungin verteiltenUmgebungeneineentscheidendeRolle.DahersollenhierMetho-denzumKomplexitatsmanagemententwickelt werden.� Als eineschwierigeHerausforderungstelltsichweiterhinderUmgangmit Schutzrechten,wiez.B.dengeistigenEigentumsrechten,vondigitalenInformationenin vernetztenUmgebungenheraus.Ein Problem,dasim Zugeder Digitalisierungvon Wissenallgemeinan Bedeutunggewinnt.

2.2 Digitale Dokumente

Ein Dokumentstellt InformationenuberraumlicheoderzeitlicheInhaltebzw. Sachverhaltefur dendauerhaften,menschlichenGebrauchbereitundnutztein Tragermedium,auf dasdie eigentlichenInformationenmit einerbestimmtenSyntaxundSemantikaufgebrachtwerden.Dokumentekonnenin analogeroderdigitalerFormvorliegen,wobeiin beidenFallendieeigentlichenInhaltedurcheineubergreifendeStruktur geordnetwerden.Die Digitale Bibliothek arbeitetausschließlichmit derdigitalenFormvonDokumenten,die jedochdurchDigitalisierungvonanalogenDokumenteneinerbestehendenBibliothekssammlungerzeugtwordenseinkonnen.Zur EinordnungvonDokumentenkanneineKlassifizierungnachder Art desInhaltsdienen[EF00], die folgendeDokumenttypenunterscheidet:� Referenzwerke: Bibliothekskataloge,Produktkataloge,Faktendatenbanken, Gesetzestexte,

Lehrbucheretc.� Primare Textveroffentlichungen: Produktspezifikationen, Forschungsberichte,Monogra-phien,Tageszeitungenetc.


� Druckbare Nicht-Text-Dokumente: Bilder, technischeZeichnungen,Karten,Handschriften,wissenschaftlicheMeßreihenetc.� Nicht-druckbare Dokumente: Audio-Aufzeichnungen,Filme, Simulationenund Animatio-nen,Multimedia-Produkte.

Abbildung2.2: BeispieldokumentFlughafengebaude.Quelleder Einzelbilderund Modelle: ETHZurich,FachbereichArchitektur.

Die letztgenannteKategorievon DokumentenkanndurcheineentsprechendeAufarbeitungindruckbareDokumenteumgewandeltwerden,z.B. kannauseinerSimulationeineMomentaufnah-meeines3D ModellsdurchVisualisierungalsBild extrahiertwerdenodereineAudio-AufnahmekanndurchVisualisierungdesSprachspektrumsdargestelltwerden.DieseKonvertierungvon Do-kumentreprasentationenwird im folgendennocheingehenderbehandeltwerden.ZusammengesetzeDokumente,wie siein DigitalenBibliothekenmoglichwerden,enthaltenverschiedeneKomponen-tendesjeweiligenDokumenttyps,wie z.B.dasobengenannteBeispieldokumentubereingeplantesFlughafengebaude.Hier sindTeile ausProduktkatalogen,eventuellForschungsberichteuberSpe-zialaspektedesFlughafenbaus,Bilder undtechnischeZeichnungenunddanebenauch3D Modellebzw. Filme zu einemGesamtdokumentzusammengefuhrt. In Abbildung2.2 ist ein solchesDoku-mentesmit Hilfe einesentsprechendenDL-Interfaceszur Darstellungauf demBenutzerbildschirmgezeigt.Fur dasgesamteDokumentodereineKomponentekannesnotwendigsein,die geistigenEigentumsrechteoderspezielleZugriffsrechtezu wahren,wennBenutzermit ihnenarbeiten.Ver-schiedeneAnsatzehierfur werdenebenfalls im folgendenbeschrieben.


2.2.1 Aufbau digitaler Dokumente

Die Bereitstellungvon heterogenenDatenals DokumentedigitalerBibliotheken und derenBear-beitungdurchBenutzerwird durchdie Trennungvon Strukturund Inhalt unterstutzt. Die mit denDokumentengespeicherteStrukturinformationermoglichtdieschnelleSuchevon Inhalten,diege-zielte Interaktionund auchdie Kooperationvon mehrerenBenutzernmit dendigitalenInhalten.Die InhalteeinesDokumenteswerdenhieralsBlattereinerBaumstrukturdargestellt,diedurchver-schiedeneArten von Knoten (Hauptknoten,Gruppenknoten,Ressource-Knoten,Attribut-Knotenetc.)untergliedertist undsodieStrukturdesDokumenteswiedergibt. Teildokumente,KapiteloderKomponenteneinesDokumenteswerdenin dieserBaumstrukturdurchGruppenknotenangezeigt.Ressource-Knotenenthaltendie ObjekteundderenDaten,alsodeneigentlichenInhalt. UbereineeindeutigeReferenzierungkannauf dieseDatenzugegriffen werden.Die Attribut-KnotenweisenjederGruppeunterhalbeinesKnotensbestimmteMerkmalezu,die denInhalt genauercharakteri-sieren,alsoz.B. denFont und die FontgroßeeinesTextesoderdie Zugriffsrechtefur die Objektein dieserGruppe.In Abbildung 2.3 ist der hier beschriebeneAufbau von digitalenDokumentengezeigt.

Abbildung2.3:TrennungvonStrukturundInhalt vonDL Dokumenten

Zu jedemKnotenwerdenZusatzdatengespeichert,die dasArbeitenmit denDokumentinhal-tenermoglichen,ohnesofortdirektaufdieDatenzugreifenzumussen.DieseZusatzinformationenwerdenalsMetadatenbezeichnet(siehehierzu[Del99]). WenneinBenutzernachbestimmtenDo-kumenteneinerDigitalenBibliotheksuchenmochte,wird erzunachstaufdieMetadatenzugreifen,bevor dieeigentlichenDatendesInhaltsbenutztwerden.Eswird daherbeimArbeitenmit digitalenDokumentenzwischenmetadaten-basiertenMethodenundinhalts-basiertenMethodenunterschie-den.Dametadaten-basierteMethodensehrviel effizienterim Umgangmit Systemressourcensind,werdensiefur Retrieval undZugriff vonDL-Dokumentenmeistenseingesetzt.Inhalts-basierteMe-thodenkonnenin vielenFallengenauereInformationenzueinemDokumentliefernundhabenauchdenVorteil, fur dynamischsichanderndeBestandevonDigitalenBibliothekenautomatischZusatz-informationengenerierenzukonnen.


2.2.2 Eigenschaftenheterogenerund komplexerDokumente

Digitale Bibliotheken zeichnensich unteranderemdadurchaus,daßsieesermoglichen,mit sehrkomplexenundausmehrerenKomponentenzusammengesetztenInformationenumzugehen.Hete-rogenitat und Komplexitat als Eigenschaftenvon DL-Dokumentensollenhier dahergenauerbe-schriebenwerden.Die Klassifizierungin Abschnitt 2.2 hat zwischenmehrerenDokumenttypenunterschieden.Ein DokumentkannaußerdemausmehrerenKomponentenmit verschiedenenDa-tentypenzusammengesetztwerden.Dies fuhrt zu folgenderBeschreibung einesheterogenenDo-kuments:� HeterogeneDokumentesind ausverschiedenenDokument-und Datentypenzusammenge-

setzt.ZurBeschreibungundzumArbeitenmit solchenDokumentenwerdendiezugeordnetenMetadatenundenthaltenenStrukturinformationenverwendet.Hierbeiwird weiterzwischeneinerubergeordneten,einheitlichenDokumentstrukturundeinerspezifischenKomponenten-strukturunterschieden.

DasobigeBeispieldokument(Abb. 2.2) enthalt eineDokumentstruktur, die Textkapitel,Uber-schriftenetc,unterscheidbarmachtund eineKomponentenstrukturfur dasintegrierte3D-ModelldesGebaudesin FormdesSzenengraphen(hierOpenInventor[Wer98]).

Die Komplexitat einesDokumenteskannnicht in FormeinesZahlenwertesangegebenwerden,da diesesMerkmal subjektiv ist. Ein Benutzer, der zum erstenMal mit einemkomplexen Doku-mentkonfrontiertwird, wird ersteinmaldamitbeschaftigt sein,eineUbersichtuberStrukturundInhaltzugewinnen.BeimweiteremUmgangdamitwird sichaberdieKomplexitat subjektiv weiterreduzieren,daderBenutzerErfahrungsammeltbzw. ubergeordneteStrukturenerkennt.DurcheineabgestufteAnderungdesAuflosungsgradesderWahrnehmungkannein BenutzerwahrenddesAr-beitensmit einemDokumentzwischeneinerglobalenNavigationin derStrukturundlokalerInter-aktionauf inhaltlicherEbenewechseln.Die folgendeBeschreibungvon komplexenDokumentenkanneinKriterium andieHandgeben,wannvonKomplexitat gesprochenwerdenkann:� Die Komplexitat einesDokumentesist umsogroßer, je mehrKnotenbzw. Objekteesenthalt

undje mehrVerknupfungenzwischendiesenbestehen.

Als Beispielkannmansichein digitalesBuchmit vielenReferenzen,FußnotenundQuerver-weisenvorstellen,oder Verbindungenvon 3D AnimationeninnerhalbeinesDokumentsmit be-stimmtenStellenin einemTextkapitel.Fur ein3D Dokument,dasaussehrvielenObjektenbesteht,steigtdieKomplexitat mit derAnzahlderObjekteundmit derMengeanVerknupfungenzwischenihnen.

2.2.3 Digitale Dokumentein relationalenDatenbanken

ZurstrukturiertenSpeicherungvongroßenDokumentkollektionenwerdenDatenbankenverwendet,die esermoglichen,alle enthaltenenDokumentdateieneinheitlichzuzugreifenund zu bearbeiten.DurcheineDatenbank(DB) wird garantiert,daßdie Datendauerhaft(persistent)undweitgehendredundanzfreigespeichertwerden.Zur Verwaltungder Dokumentbestandewird eineDatenbank-Management-System(DBMS) verwendet,daseinanwendungsunabhangiges Arbeitenmit denDa-tenbestandenermoglichtunddieKonsistenzderDatenbankerhalt. UntereinemDatenbank-System(DBS)wird meistensdieKombinationeinesDBMS mit einerodermehrerenDatenbankenverstan-den.


EsexistierenverschiedeneDatenbank-Modelle,die festlegen,wie dieDateninternzusammen-gefaßt und verwaltet werden[HS00]. Ein Datenbank-Modellist ein Systemvon KonzeptenzurBeschreibungvonDatenbankenundlegt SyntaxundSemantikvonDatenbankbeschreibungen fest.Die wichtigstenModellesinddasrelationaleDatenbank-Modell,dasschonrelativ langeentwickeltwird und sich starkdurchgesetzthat,und dasobjekt-orientierteDatenbank-Modell.Beim relatio-nalenDatenbank-Modellwerdendie Inhaltein Form von Tabellendargestellt,fur die bestimmteBeziehungen(Relationen)untereinanderfestgelegt sind.Die ZeileneinerTabelleentsprechenTu-pelneinerRelationundbildendie gespeichertenDatensatze.Die SpalteneinerTabellewerdenalsAttributebezeichnetundmit einemAttributnamenversehen.

Abbildung2.4:Entity-Relationship-Diagramm fur DL Dokumentein relationalenDatenbanken.

Um mit denInhalteneinerDatenbankarbeitenzukonnen,sindGrundoperationenwie Mengen-operationen,Projektion,Selektion,VerbundundUmbenennung,auf denTabellenfestgelegt (siehehierzu[CHRS98]).EinelogischzusammengehorendeEinheitvoneinerodermehrerenDatenbank-operationenwird alsTransaktionbezeichnet.Im Mehrbenutzerbetriebsorgt dasDBMS dafur, daßkonkurrierendeTransaktionenkoordiniertwerdenunddieDatenbankjederzeitin einemkonsisten-ten Zustandist. DieseAufgabewird auchals Synchronisationbezeichnet.TransaktionenwerdenhaufiganhandderACID-Eigenschaften(A-Atomicity, C-Consistency, I-IsolationundD-Durability)charakterisiert.� Atomicity: Transaktionensindgrundsatzlichatomar. Eswerdenentwederalle Anweisungen

einerTransaktionvomDBMS ausgefuhrt oderkeine.� Consistency: Transaktionenuberfuhren eine Datenbankvon einem konsistentenZustandin den nachstenkonsistentenZustand.InkonsistenteZwischenzustandewerdenfur andereTransaktionennichtsichtbar.


� Isolation: JedeTransaktionlauft in einemvom DBMS simuliertenEinbenutzerbetriebab.� Durability: Die ErgebnisseeinererfolgreichenTransaktionsinddauerhaftin derDB gespei-chert.

Wie im letztenPunkterkennbarist, wird zwischenerfolgreichabgeschlossenen(COMMIT)und mit Fehlerabgebrochenen(ROLLBACK) Transaktionenunterschieden.Bei einemRollbackwird dieDatenbankin denletztenkonsistentenZustandzuruckgefuhrt.Zur FormulierungvonOpe-rationenund damit zur Abfrageder Datenbankwurdedie SpracheSQL (StructuredQueryLan-guage)entwickelt. Sie hat sich ebenfalls in hohemMaßedurchgesetztund wird dahervon allenDatenbankanbieternunterstutzt. Operationenund TransaktionenwerdenalseineReihevon SQL-Anweisungenausgedruckt.

Im weiterenwird nur auf relationaleDatenbanken eingegangen,da sie fur die AufgabenimRahmenderProblemstellungausreichendundbreit verfugbarsind.Zur BeschreibungeinerDaten-bankanwendungwird einDatenmodellverwendet,dasdenAufbauderTabellenunddieRelationenzwischenihnen festlegt. Durch ein sogenanntesEntity-Relationship-Diagramm kannein solchesDatenmodelldargestelltwerden.In Abbildung 2.4 ist die StruktureinesdigitalenDokumentesinForm einesEntity-Relationship-Diagramms gezeigt.Die Knotender Dokumentstruktursind hierals Tabellenbzw. EntitateneinesrelationalenDatenmodellswiedergegeben.NebendenMetada-ten, die durch skalareWerte reprasentiertwerden,sind in Tabellenfeldernauchdie eigentlichendigitalenDatenalsBinarobjekte(BLOB = BinaryLargeObject) angelegt. Als Alternative kannal-lerdingsaucheineReferenzin dementsprechendenFeldaufdasDatenobjektim einemFilesystemverweisen.

Ein geeignetesDatenmodellin einerrelationalenDatenbanksiehtubergreifendeDokumentkno-tenwie Dokumentcluster, Dokument,Teildokumentetc.,vor undordnetdie Inhaltemit Hilfe voneindeutigenKennungendenKnotenzu.Ein solchesModell wird z.B.vonBorowski etal. [BBH00]beschrieben.Mit Hilfe derMetadatenund derAbfragesprachenSQL konnenInhalteeinerDoku-mentkollektion direkt gesucht,verandertoderextrahiertwerden.Die BeziehungenzwischendenEntitatenwird durchVerbindungslinienangegeben.Fur einDokumentgilt hierz.B.,daßesmehre-re Teildokumentehabenkann.Umgekehrtgehort ein Teildokumentgenauzu einemDokument.IndenFeldernderTabellensinddieentsprechendenMetadatenfur dieEntitat angegeben.NebendemUrheberundSchlagwortensindauchZugriffsrechtenundFormateim Beispielangegeben.DurchdieseStrukturierungund die zugehorigenMetadatenist dasgezielteArbeitenmit denDokumen-teninhaltenbeigleichzeitigerWahrungvonZugriffsbeschrankungenmoglich.

Bei denbinarenInhaltsobjektenkannessichumbeliebigeDatenformatefur Audio, Bilder, Vi-deooder3D Geometriehandeln.Beim Arbeitenmit solchenInhaltenundbeimAuslesenkonnenanhandderMetadatendie InformationenuberdiebenotigtenunderlaubtenAnwendungsmethodenan die jeweiligen Anwendungssystemeubergebenwerden.Die Benutzungvon heterogenDoku-mentenin verteiltenUmgebungenkannaufdieseWeiseorganisiertundunterstutzt werden.

2.3 3D Dokumentein Digitalen Bibliotheken

Als digitales3D Dokumentwird in dieserArbeit ein Dokumentbezeichnet,dasals Ressource-Knoteneinebzw. mehrere3DKomponentenenthalt oderselbsteinevollstandige3DSzenedarstellt.Solche3D Dokumentewerdenim Prinzip uberallverwendet,wo 3D Szenenmit entsprechendenAnwendungenverarbeitetwerden.Also z.B. in denBereichenIngenieurwesen,Architektur, Design


oderMedizin,dieschonseitlangererZeit 3D Datenin spezialisierterFormmit Computernbearbei-tetundgenutzthaben.Im ZugederAusbreitungdigitalerBibliothekenwerden3D Dokumenteaberin sehrviel allgemeinererWeisevoneinembreitenAnwenderkreisverwendetwerden.Gleichzeitigwerdendiezuganglichen3D Informationenimmerkomplexer. DieseneueNutzungsformerfordertVerfahrenzur Handhabung großer3D Szenenin verteiltenInformationsraumen,wobeiKombina-tionenvon bekanntenund neuenAnsatzendenbreitenAnforderungenam bestengerechtwerdenkonnen.Die in dieserArbeit beschriebeneund untersuchteSoftware-Architekturstellt einensol-chenneuenAnsatzdar, beidemlokaleundRemote-Visualisierungvon3D Dokumentendynamischkombiniertwerden,umdenAspektenSicherheit,NetzanbindungundlokalerClient-PerformanzinheterogenenUmgebungengerechtzuwerden.

Abbildung2.5:Szenengraph-Strukturmit Pfadinformationin OpenInventor

Wie die allgemeinendigitalenDokumente,die obenbeschriebenwurden,enthaltenauch3DDokumenteStrukturinformation,Inhaltsobjekte,Attributbeschreibungen undeventuellMetainfor-mationen.3D DokumentewerdenhierdaheralsUntergruppevonallgemeinendigitalenDokumen-ten beschrieben.Im Fachgebietder Computergraphikwurdenin denletztenJahrenverschiedeneKonzepteund Formatezur Beschreibung, Bearbeitungund Visualisierungvon 3D Szenenent-wickelt. 3D Szenenbestehenim Prinzip ausden3D Objekten,einerodermehrerenLichtquellenundzumindesteinerKameraeinstellung,d.h.Blickpunkt-undWinkel. Die Strukturinformationvon3D Szenenwird heutemeistensin FormeinerBaumstruktur, demsogenanntenSzenengraphenbe-schrieben,dermathematischeinengerichteten,azyklischenGraphdarstellt.An denVerzweigungenenthalt der SzenengraphwiederumverschiedeneKnotenartenzur Gruppierungvon ObjektenundUntergraphen.Durch AngabeeinesPfadesin demSzenengraphkannein Objekt eindeutigrefe-renziertwerdenundsogarzurWeitergabegespeichertwerden.JederKnotenentsprichteinemfest-gelegtenTyp, z.B. Gruppenknoten,Formknoten,Materialknotenetc.,undenthalt eineAnzahlvon


Feldernmit variablenWerten,die zur BeschreibungderParameterder3D Szenenbenutztwerden.In Abbildung 2.5 ist ein Szenengraphdargestellt,wie er von der OpenInventorVisualisierungs-Softwareverwendetwird. Der Vergleichmit Abbildung2.3zeigt,daßbeideDarstellungsarteneinDokumentmit ahnlichemAufbauwiedergeben.

Die geometrischenInhalte werdendurch die Formknoten(OpenInventor: ShapeNodes)imSzenengraphenreprasentiert.In denFeldernderFormknotensinddie eigentlichengeometrischenDatenabgelegt, z.B. der Radiusund Mittelpunkt einerKugel bei geometrischenPrimitiven oderKoordinateneinesDreiecksbei 3D Maschennetzen.Die wichtigstenBeschreibungsartenvon Geo-metrieinformationsindheutePolygon-bzw. Dreiecksnetze,implizite Funktionsdarstellungen geo-metrischerPrimitive (Kugel, Quader, Konusetc.), parametrisierteKurven bzw. Flachen(Spline,Bezier-Kurvenetc.)[FDFH90]undOberflachenauszusammengesetztenElementenparametrisier-ter Flachen(Subdivision-Surfaces) [Loop87]. Polygonale3D Netze,die vielfachVerwendungfin-den,habendenNachteil,daßsienicht mathematischexakt unddamitauchnicht parametrisierbarsind.Fur 3D Dokumentein verteiltenUmgebungenbedeutetdies,daßdieeigentlicheModellierin-formationin einemsehrfruhenStadiumverlorengehtunddahernichtin derweiterenVerwendungs-ketteder3D Szenengenutztwerdenkann.Außerdemwird derUmgangmit Komplexitat durchdiefruheErzeugungvon 3D Netzenim Tesselierungsschritterschwert.Hier wird daherversucht,dieEinschrankungauf 3D Netzezu vermeidenundstattdessenmit denReprasentationenvon 3D Ob-jektenzu arbeiten,die sichfur die gegebenenAnforderungenambesteneignen.Auf verschiedeneReprasentationenvonObjektenwird im folgendenKapitel3 genauereingegangen.

Zur vollstandigenBeschreibungvon 3D DokumentenwerdenweiterhinMaterialeigenschaftenbenotigt, die Angabenuberdie Oberflacheneigenschaften, wie z.B. FarbeoderReflexion, von Ob-jektenmachen.Die Materialeigenschaftensind im Szenengraphenals Attributknotenund durchderenFelderwiedergegeben.Zur einfacherenHandhabung werdenhaufig Texturenzur Modellie-rungderObjektoberflachebenutzt,d.h.eswerdenBilder aufdiegeometrischeFormprojiziert.Umdie Visualisierungzu unterstutzen,sind in 3D DokumentenauchLichtquellenundKameraknotenmit Blickwinkel- undpositionenenthalten.Metainformationen,wie z.B.ObjektnamenoderRecht-einformationen,konnendurchspezielleFeldermit denKnotenverknupft werden,sodaßsiebeiderVerarbeitunggenutztwerdenkonnen.

Bei der interaktiven Visualisierungvon 3D Dokumentenlaufendie folgendenSchritteab. So-bald die 3D Datenin einegeeigneteAnwendunggeladenwerden,wird die StrukturinformationzumAufbaueinesSzenengraphenin Form einerinternenSzenendatenbankverwendet.Zur Visua-lisierungderSzenewird derSzenengraphvon obennachuntenvollstandigdurchgegangen.DabeiwerdenAktionen auf denSzenengraphenangewendet.Beispielefur Aktionen, die dabeiauf dieSzeneoderTeilszenenangewendetwerdenkonnen,sindRendering,Pickingund die BerechnungvonBounding-Box-Information.Die Bounding-Boxeines3D Objektesist einQuadermit minima-lem Volumen,derdasObjektvollstandigumschließt.VerschiedenemoderneGraphik-APIsnutzensolcheSzenengraphen,um die Entwicklungvon interaktiven Visualisierungsanwendungen zu un-terstutzen.Oft verwendeteFormatezurBeschreibungvon3D DokumentensinddasOpenInventor-Format IV [Wer98], dasVRML-Format[BK96], dasspeziellfur die Verwendungvon 3D Datenim WWW entwickelt wurde,oderdasOBJ-Format.Es existierenjedochnochzahlreicheandereFormate,diehiernichtaufgefuhrt werdensollen.


2.4 Sicherheitsaspektevon digitalen 3D Dokumenten

DigitaleBibliothekenerlaubendenZugriff aufalleFormendigitalerDokumentein verteiltenInfor-mationsraumen,d.h.in Systemenvon Computern,die durchein lokalesoderdurchTelekommuni-kationsnetzestandigodernurzeitweiseverbundensind.DieheutewichtigsteundverbreitetsteFormeinesverteiltenInformationsraumesist aufbauendauf demInternetdasWorld-Wide-Web (WWW).In Kombinationmit lokalenIntra-Netzenwird dasWWW zueinersehrflexiblenBasisfur DigitaleBibliotheken,dadie Verfugbarkeit desangebotenenWissenslokal undglobalstarkanwachst.DiebreiteVerfugbarkeit von digitalenDokumentenwirft aberauchProblemeauf, die fur ein lokalesAngebotvon analogenInformationen,wie Buchern,Bilddrucken oderTontragernin herkommli-chenBibliotheken, nicht in einemahnlichenMaß entscheidendwaren.Durch denUbergangvonanalogenzudigitalenMedientritt dasProblemauf,daßInformationenbeliebigoft ohneQualitats-verlustkopiert werdenkonnen.Bei analogenMedientretenbei wiederholtemKopierenGenerati-onseffekte auf, die hohequalitative Einbußengegenuberder Originalqualitat schonnacheinigenwenigenVervielfaltigungsschritten bedeuten.DieshattedenEffekt, daßgeistigeEigentumsrechteeinfachergeschutzt werdenkonntenundCopyright-Verletzungenseltenerwaren.DasOriginal ei-nesanalogenDokumentesmit hoherQualitat blieb immerbeimBesitzer, solangeer esnicht unterfestgesetztenBedingungenweitergab. Fur digitaleMedienkanndieserEffekt nichtgenutztwerden,um dasgeistigeEigentumsrechtrealzu schutzen.SobaldeineKopieangefertigtundverteilt wird,existiertein identischesReplikatderDaten,dasbeliebigoft undrelativ einfachweitergegebenwer-denkann.Im Zusammenhangmit derGewahrleistungvon UrheberrechtensindweiterhinauchdieZugriffskontrolle auf Datenund derenIntegritat in verteiltenInformationsraumenin besonderemMaßzubeachten.Beispielefur solcheschutzenswertenDatensindtechnischeDokumenteim Inge-nieurbereichoderpersonenbezogeneDatenin derMedizin, aberauchkunstlerischeArbeiten,wievirtuelleWeltenoderMusikaufnahmen.

Sicherheitsanforderungen in verteilten Informationsraumen

DieseProblemefuhrtenzurEntwicklungverschiedenerVerfahrenzumSchutzvondigitalenDoku-mentenin derInformationstechnik. Die wichtigstenSicherheitsanforderungen, die hierbeiberuck-sichtigtwerden,sindim folgendenaufgefuhrt undgenauerbeschrieben[Dit00]:� Urheberrechte: Schutzvon geistigemEigentum,Eigentumer- und Benutzerkennzeichnung,

VermeidungundAufdeckungvonCopyright-Verletzung� Zugriffskontrolle: WirksameMethodenzur Kontrolle desSystemzugangsund Zugriffsbe-schrankungenaufSystemfunktionenundDatenbanken.� Integritat: Erkennungvon Abweichungenvon denOriginaldatenverursachtdurchManipu-lationoderUbertragungsfehler. Methodenzur Uberprufung.� Authentizitat: Moglichkeitenzur Identifikationvon Sendern,EmpfangernundDokumenten,d.h.Authentifizierungvon KommunikationundDaten.� Vertraulichkeit: Schutzvor Zugriff auf vertraulicheDatendurchUnbefugteauf demServeroderbeiderUbertragung.


2.4.1 Verfahren zur Berucksichtigungder Sicherheitsaspekte

Verfahrenzur RealisierungdergenanntenAnforderungenwerdenhauptsachlichim FachgebietderKryptologie untersuchtund weiterentwickelt. Dabeiunterteilt mandiesesGebietin die Krypto-graphie,KryptoanalyseundSteganographie.Die Kryptographiebeschaftigt sichmit MethodenzurTransformationvon Datendurch Verschlusselungzur Authentifizierung,Identifizierungund Er-stellungdigitalerSignaturen.Die KryptoanalyseuntersuchtVerfahrenzur RucktransformationderDatenunddamitauchAngriffe auf die kryptographischenVerfahren.Die Steganographieschließ-lich entwickelt Methodenzur verdecktenKommunikationvon Daten,sodaßunbefugteDritte voneinemAustauschder geschutztenDatenkeineKenntnisbekommenkonnen.Als Beispielsei diegeheimeUbertragungvon Informationenin Bilddatenstromengenannt,bei derdie RedundanzundIrrelevanzdervisuellenTragerdatengenutztwird, um die eigentlicheKommunikationin denBil-dernzuverstecken.

Nebender Verschlusselungist ein weiteresVerfahrenzum Schutzvon Urheberrechtenunddaruberhinauszur Echtheitsprufung die Markierungder geschutztenDatendurchWasserzeichen,wie esseitlangemim analogenBereich,z.B.beiGeldscheinen,erfolgreichpraktiziertwird. Digita-le WasserzeichenwerdenalszusatzlicheDatenin dasOriginaldokumenteingebrachtundmoglichstrobustmit denDatenverknupft. DasWatermarkinghatsichausderSteganographieentwickelt undist heuteeinwichtigeseigenesForschungsgebiet.Wasserzeichenkonnensichtbarin einDokumenteingebrachtwerden,damit eine Identifizierungder Datenjederzeitvisuell geschehenkann,odernicht-wahrnehmbarin denDatenverstecktwerden.Fur nicht-wahrnehmbareWasserzeichenunter-scheidetmandie Einbettungder Watermark-Nachrichtenin ein Tragerdokument(Cover, CarrieroderauchOriginal) und denAbfrageprozeß(Watermarkretrieval) [Dit00]. Bei derAbfragewirdmit einemgeheimenSchlusseldasTragerdokumentso verarbeitet,daßdie Watermark-Nachrichtausgegebenundals richtig erkanntwerdenkann.DieserSchrittwird zumNachweisderUrheber-schaftundzurUberprufungbzw. zumAuslesenvonzusatzlichenInformationen,wie Kundendaten,Kopienummeretc.,verwendet.

2.4.2 Mangelder heutigenVerfahren

Die genanntenVerfahrenkonnengenerellauf digitale Datenangewendetwerden,jedocherfor-derndie verschiedenenDatentypen,wie Text, Bilder, Video,Audio und3D Szenen,einespezielleAnpassungder Methoden.Beim Watermarkingwerdenin denmeistenFallen die Komponentenvon zusammengesetztenDokumentenmit eigenenWasserzeichenversehen,die untereinanderkei-neVerknupfungbesitzen.Dadurchwird der Schutzvon heterogenenDokumentenerschwert.Fur3D Szenenexistierenim BereichWatermarkingfastausschließlichVerfahren,die auf polygonalen3D Netzenarbeitenund die Manipulationder Netzmaschenzur EinbringungdesWasserzeichensverwenden.Zur Kennzeichnungvon anderenReprasentationsformenvon 3D SzenensindwenigeMethodenbekannt.Ein allgemeinanwendbaresundrobustesVerfahrenzumSchutzvon3D Doku-mentenexistiert heutenicht, sodaßein KonzeptzumManagementvon SicherheitsanforderungenuberreinekryptographischeVerfahrenhinausgehenmuß.DieseSichtweisewird auchvon Bisselet al. [Bis00] nacheinerEvaluationexistierendenVerfahrenzumSchutzdurchWasserzeichenfurdigitalenAusstellungsobjektenvon Museenbestatigt.


2.4.3 Skizze eines umfassendenManagement-Szenariosfur Schutzrechte von 3DDokumenten

Zur KonzeptioneinesumfassendenManagement-SzenariossolltenfolgendeSchritteberucksichtigtwerden:Authentifizierungvon Kundeund Anbieter, Kommunikationvon bestehendenRechten,Verhandlungvon neuenRechtenundAustauschvon Dokumentreprasentationen, die andenaktu-ellenStandderRechtesituationangepaßtwerdenkonnen.Dokumentreprasentationen konnenz.B.durchEinbettungvonWasserzeichen,AnhangenvonSignaturen,Transformationin eineandereRe-prasentationsformoderdurchdirekteKopieerzeugtwerden.Ein Kunde,derkeineRechtezurKopieeinesOriginaldokumentserworbenhat,erhalt einDL-Dokumentin einerniedrigenQualitatbzw. ineinerReprasentationsformmit geringemInformationsgehalt.Erwirbt er mehrRechtebis hin zumKauf desOriginals,bekommt er schrittweiseimmer mehrInformationuberdasDokument.EineVerschlusselungder ubertragenenDatenmit symmetrischenoderasymmetrischenVerfahrenkanndasGesamtkonzeptvervollstandigen.In Abbildung2.6ist einSchichtenmodellfur einSicherheits-konzeptgezeigt,dasprinzipiell vom Aufbau desMultimedia-secure Gateway von NahrstedtundQiao[NQ98] abgeleitetist.

Abbildung2.6:SchichteneinesManagement-Szenarios.

Um einsolchesSzenarioumsetzenzukonnen,wird ein internesDokumentmodellbenotigt, dasMoglichkeitenzur Integration,Evaluationund Extraktionvon sicherheitsrelevantenDatenbietet.Ein internesDokumentmodellwird beim EinlesendesDokumentes,z.B. auseinerDatenbankineineAnwendung,generiertundfolgt festgelegtenRegeln.Hierfur eignetsichbesonderseinobjekt-orientiertesDokumentmodell,beidemalleBestandteileunddasDokumentselbstdieEigenschaftenvon Objektenim objekt-orientierten Sinnhaben:die eigentlicheObjektdatenwerdengekapselt,esexistiert eineeindeutigeIdentifizierungfur jedesObjektundZugriffsmethodensind in einerwohldefiniertenSchnittstellefestgelegt. Ein Beispiel ist z.B. dasDocumentObjectModel: DOM desWorld WideWebConsortiumsW3C[DOM00].

In Abbildung2.7ist einDokumentmodellgezeigt,dasdiebeschriebenenEigenschaftenfur 3DDokumenteumsetzensoll. Ein Dokumententhalt ein odermehrereObjekte,die als KnoteneinerBaumstrukturdefiniert sind. Die eigentlichenObjektdatensind ebenfalls Knoten desjeweiligenDatentyps.Die Objektesind im Dokumentgekapseltund durcheineSchnittstellevon Methodenzuganglichgemacht.DieseSchnittstelleumfaßtim wesentlichenMethodenfur Erzeugung,Retrie-


Abbildung2.7:Objektmodellzur Integration,EvaluationundExtraktionvonSicherheitinformatio-nenfur digitaleDokumente.

val undVerteilungvon Dokumenten.Außerdemwerdendie Methodenzur Integration,ExtraktionundEvaluationvon Sicherheitsinformationenfestgelegt.

Die Sicherheitsinformationen, die in dasDokumentintegriert werdensollen,beziehensichaufdie Zugriffskontrolle,die Urheberschaft,die Authentizitat unddie Integritat von Objektdaten.DiekryptographischenVerfahren,die obendiskutiertwurden,funktionieren,indemzusatzlicheDatenaneinObjektangehangt(DigitaleSignatur)werdenoderdurchEinbettungderDatenin dasObjektselbst(Watermarking).EsmussendaherMethodenzumAnhangenundEinbettendiesersicherheits-relevantenDatenfur denjeweiligenDokument-undDatentypgefundenwerden.NebenderIntegra-tion von DatensindauchMethodenzur EvaluationundExtraktion(vgl. Abbildung2.7)notig, umin einerAnwendungZugriff auf diesicherheitsrelevanten Datenzuerlauben.Um dasArbeitenmiteinemDokumentzu optimieren,stehenim DokumentselbstverschiedeneIndizeszur Verfugung,dieVerknupfungenmit denObjektenenthalten.Ein Index fur die ZugriffskontrolleermoglichtdenAbgleichmit denZugriffsrechteneinesBenutzers,dermit bestimmtenObjektreprasentationen ar-beitenmochte.

2.4.4 Reprasentationund Integration von Sicherheitsinformationen

In diesemAbschnittsollendie Methodenzur Integration,Extraktionund Evaluationvon sicher-heitsrelevantenZusatzinformationenwahrendderBearbeitungvon3D Dokumentendiskutiertwer-


den,die in Abschnitt2.4.3fur allgemeineDokumentebeschriebenwurden.Die fur einSicherheits-mangementbenotigteFunktionalitatumfaßtdieUrheberidentifizierung,Kundenidentifizierung,Ko-pienkontrollebzw. denSchutzdesOriginals,die Nachweisbarkeit derUnversehrtheitundVertrau-lichkeit durchZugriffskontrolle.Fur dieRealisierungdieserAufgabenwerdenzusatzlicheDatenandie ObjektdateneinesDokumentesangehangtoderdarineingebettet,meistin der Form von Text(1D) oderMustern(2D, 3D).

Die einfachsteFormvonInformationenzumSchutzdesUrheberrechtsist eineTextkettemit denMetadatendesObjektes,die z.B. im Dublin- Core-Formatvorliegenkonnen,alsoz.B. Informatio-nenuberdenAutor, dasEntstehungsdatumunddenEigentumer. DersogenannteDublin-Corewirdin derPraxisoft verwendetundlegt einenSatzvon Attributenzur Beschreibungvon DokumentendurchMetadatenfest(siehe[WKL98]). DasfolgendeBeispielreprasentiertein3D Dokumentbzw.Objekt,dasdurchseineMetadatenim Dublin-CoreFormatidentifiziertwerdenkann:

”Metadaten: ID , Author, Entstehungsdatum,Eigentumer, Copyright ::

Document-Distribution-Class:KlasseB (KopiealsDreiecksnetzerlaubt):: Auflosung:KlasseB-Wert � “

NebendenMetadatensindTextdateneingefugt, die Aufschlußuberdie Bedingungenbei derVerteilungvon Kopiengeben.EskanneineKlasseneinteilungfur Objektevorgenommenwerden,die dieseBedingungenwiedergibt, alsoz.B. KlasseA fur Objekte,die alsOriginal verteilt werdendurfen,undKlasseB fur solche,dienuralsDreiecksnetzweitergegebenwerdendurfen.Als weitereInformationwird ein Wert eingefugt, derAufschlußuberdie maximaleAuflosungvon Objektko-pien angibt. Im Fall von Netzreprasentationenalso die Großeder Dreiecksmaschen.Mit diesenInformationen,diealsText oderSignaturaneineObjektangehangtwerden,oderin codierterFormalsWasserzeichenmusterin die Objektdateneingebrachtwerden,kanndie obengenannteFunktio-nalitat weitgehendrealisiertwerden.

Die gangigstenTechnikenzurIntegrationarbeitenmit Watermarking,inhalts-basiertenSignatu-ren([DSS99])undVerschlusselung.In Tabelle2.1wird einekurzeBeschreibungderverschiedenenMethodenmit ihrenEigenschaftengegeben.

BeimWatermarkingwerdenMusteroderin MustercodierteTexteeingebracht.Manunterschei-det:wahrnehmbarebzw. nichtwahrnehmbare,blindebzw. nicht-blindeundschließlichrobustebzw.fragileWasserzeichen(siehe[KP00]). Die Bezeichnungnichtblind bzw. blind beziehtsichdarauf,ob zur RekonstruktiondesWasserzeichensdie Originaldatenbenotigt werdenodernicht. Robustbedeutethier Bestandigkeit gegenuberManipulationender Originaldaten.FragileWasserzeichensollengeradeim Fall bestimmterManipulationenzerstort werden.Im Fall derVerschlusselungwer-dendie Schlusselinformationenin einersicherenForm zur Verfugunggestellt.Man unterscheidetsymmetrischeVerfahren,bei denendergleicheSchlusselfur CodierungundDecodierungverwen-detwird, undassymmetrischeVerfahren,die mit einemoffentlichenSchlusselzur CodierungundeinemprivatenzurDecodierungarbeiten.

Die Einbettungvon Wasserzeichenin 3D Modelleist einaktuellesForschungsgebiet.Die mei-stenderbekanntenVerfahrenarbeitenauf denGeometrieelementenvon 3D Netzen.DadurchwirdderEinsatzvon Wasserzeichenstarkeingeschrankt,da3D ObjektebestehendausparametrisiertenOberflachennichtdirektmarkiertwerdenkonnen.ErstnachdemTesselierungsschrittkonnenauchhier Wasserzeichenverwendetwerden.VerfahrenzumEinbringenvon digitalenInformationeninpolygonale3D Modellewerdenz.B.vonOhbuchi [OMA98] undBenedens[Ben99] vorgeschlagen.Ein Verfahrenzur Markierungvon Parameternvon Gesichtsanimationenim MPEG-4Formatwirdvon Hartunget al. [HEG98]besprochen.Die Verfahrennutzenim wesentlichendie folgendendreiAnsatzezurEinbettungvonWasserzeichenin polygonaleModelle:


Wasserzeichen Signaturen SchlusselBeschreibung Einbettungvon Extraktionvon inhalts Informationzur

Musternoder -basiertenMerkmalen, RucktransformationcodiertenTexten ErzeugungderSignatur mit einemgegebenenin Objektdaten durchLauflangencodierung, Verschlusselungs-

plusVerschlusselung algoritmusUrheber- Urheber-identifizierende Anhangender In Kombination

identifizierung MusteroderTexte, verschlusseltenSignatur, mit Signaturunsichtbar plusPublic-Private-Key

Verfahren(PPK)Kunden- Fingerprints: unsichtbare Anhangender In Kombination

identifizierung Kunden-identifizierende verschlusseltenSignatur mit SignaturMusteroderTexte plusPPK-Verfahren

Kopien- Oft Blackbox-Verfahren DurchVerwendungkontrolle zur offentlichenVerifi-, - lizensierterHardware

zierung,unsichtbar, blind, TeilschutzMusteroderTexte moglich

Unversehrt- Unsichtbare Anhangender In Kombinationheits- fragileWasserzeichen, codiertenSignatur, mit Signatur

nachweis Mustereinbettung VerwendungvonMerk-malen,dieunzulassige

ManipulationenanzeigenVertraulich- Zugriffskontrolle Schutzdurch

keits- - durchfeste assymetrischeVer-schutz Kundensignaturen fahrenodergroße

Schlussellange

Tabelle2.1:GebrauchlicheReprasentationsformenvonSicherheitsinformationen.

� ModifikationderVertex-Koordinaten� ModifikationderVertex-Topologie� KombinationvonGeometrie-undTopologie-Modifikation

Alle VerfahrenhabendasZiel robustgegenbestimmteGeometrieoperationen,wie allgemeineTransformationen,Ausschnittsbildungbzw. lokaleDeformationodertopologischeModifikationzusein.EineDiskussionderangesprochenenVerfahrenhinsichtlichihrer Robustheitwird in [Dit00]durchgefuhrt.

Am BeispielderDigital VersatileDisc (DVD) sollenBeispielefur kombinierteVerfahrenzurDurchsetzungvonUrheberechtengegebenwerden.DaDVD Audio- undVideodatenmit sehrhoherQualitat zurVerfugungstellt,habenUrheber, ProduzentenundVerlegereingroßesInteresseanderWahrungdesCopyrights. Es sind unteranderemzwei wichtige Schutzmechanismenvorgesehen[MCB98]:� ContentScramblingSystem: Beim CSSwerdenVideodatenim MPEG-2Formatauf einer

DVD abgelegt. Dasfur die RucktransformationbenotigteSchlusselpaarwird im lead-inBe-reich der DVD abgelegt und kannbei einerVervielfaltigungnicht mitkopiert werden.NurDVD-genormteGeratekonnendie Datenabspielen,wodurchihre Verbreitungvorangetrie-benwird.


� CopyGenerationManagementSystem: Mit Zusatzinformationenim MPEG-Headerwird ge-regelt, ob die Datenkopiert werdendurfen. Es werdendie Zustande:Kopierschutz,ohneKopierschutzundEinmalkopieerlaubt.DurchVerwendungvonAbspielgeraten,diedieseIn-formationubergehen,kanndasSystemumgangenwerden.Esist alsonur fur DVD-genormteGeratesinnvoll undbautdarauf,daßdiesesichdurchsetzen.

Wie schonan dieserBeschreibung einigerMethodenzum Sicherheitsschutzder DVD zu er-kennenist, gibt esderzeitkein wirklich sicheresVerfahren,um Urheberrechtsschutzwirkungsvolldurchzusetzen.Vielmehrkonnenalle Verfahrenmit gewissenAufwandunwirksamgemachtwer-den.Fur dendigitalenBereichbedeutetdies,daßder SchutzdesOriginalsgroßeBedeutunghat.Die VerbreitungvonKopienmit einerteilweisevermindertenQualitatodervontransformiertenRe-prasentationsformenstelltdahereinewichtigeMoglichkeit zurWahrungvonUrheberinteressendar.Mit Hilfe einesobjekt-orientiertenDokumentmodells,dasdieObjektdateneinesDokumenteskap-selt und eineMethodenschnittstellezum kontrolliertenZugriff bereitstellt,und durchzusatzlicheVerschlusselungvonDatenkanneinsolchesSystemzumsicherenManagementvon3D Dokumen-tenrealisiertwerden.

2.5 Arbeiten mit digitalen Dokumentenin verteilten Umgebungen

Das in Abschnitt 2.1 beschriebeneDigital-Library-Szenariozeigt, daßein Konzeptzum Arbei-tenmit DL-Dokumentenin hohemMaßeTechnikenausdemGebietderverteiltenSystemenutzt.In diesemAbschnitt sollen die wichtigstenTechniken verteiltenArbeitensmit DL-Dokumentenunddie Anforderungenbesprochenwerden,die aneineverteilteArchitekturgestelltwerden.EineAnwendung,die Moglichkeitenanbietet,mit verteiltenProzessen,verteiltenDatenund verteiltenBenutzernumgehenzukonnen,wird alsverteiltesSystembezeichnet.EineDigitaleBibliothek,dieuberein DatennetzDokumenteundDienstefur globalverteilteBenutzeranbietet,setztin diesemSinnaucheineverteilteArchitekturzurBewaltigungihrerAufgabenvoraus.

VerteiltesArbeiten: Retrieval, interakti ve Visualisierungund Kommunikation

Um dieDiensteeinerDigitalenBibliothekzunutzen,d.h.mit denenthaltenenDokumentenarbeitenzukonnen,mussenMoglichkeitenzumRetrieval derDokumente,zumZugreifenundzumBestellenbzw. Erwerbrealisiertwerden.Fur interaktive und kooperative AufgabenwerdenauchMoglich-keitenzur Manipulationvon Dokumentreprasentationen und zur Kommunikationgebraucht.DieletzterenAspektesindvor allemwichtig, wennesdarumgeht,mit demDL-Server selbstundmitanderenBenutzernsynchronisiertzu arbeiten,um ein Rechte-Managementund kooperatives Ar-beitenfur geschutzte Dokumentezu erlauben.DieseMoglichkeiten gehenuber reinesArbeitenmit denMetadateneinerDokumentkollektion hinaus,fur dasz.B.eineKommunikationmittelsdesHTTP-Protokolls [RFC2616] ausreichenwurde.

Fur dasverteilteArbeitenmit 3D Dokumentensollendie drei Hauptaspektenocheinmalbe-schriebenwerden:� Retrieval: Um in großenKollektionenvon DL-Dokumenten3D SzenenundObjekteabfra-

genund fur weitereArbeitsschritteaussuchenzu konnen,existierenMethodenzur Abfragevon Datenbanken in verteiltenInformationsraumen.In denmeistenFallen werdenfur dasRetrieval Metadatenbenutzt,die nachtraglich fur ein Dokumentannotiertwurden.Uberei-neWWW-Schnittstelleunddie AbfragespracheSQL kannein einfachesRetrievalsystemei-nerDigitale Bibliothek realisiertwerden.Um auf denInhaltenvon Dokumentenarbeitenzu


konnen,werdeninhalts-basierteVerfahren,wie automatischeMerkmalsextraktion fur Bild-datenoderFulltext Retrieval fur Text, eingesetzt(siehehierzu [Del99]). Im Falle von 3DDokumentenwerdenhauptsachlich geometrischeMerkmaleausden Datenextrahiert undzurAbfragebenutzt[PR99].EineKombinationvon inhalts-basiertenMethodenzum3D Re-trieval undmetadaten-basiertenMethodenzurAbfragederDatenbankinformationim WWWist in [Loe00b] beschrieben.� Interaktive Visualisierung: Das Arbeiten mit 3D DokumentensetztMethodenzur 3D Vi-sualisierungvoraus,d.h. daßdurch den Rendering-Prozeßausder Geometrie2D Ansich-tenmit einemModell zur Beleuchtungssimulation erzeugtwerden.Die Rendering-Pipeline([FDFH90])kannvollstandigaufdemServerausgefuhrt (Remote-Visualisierung)werden,sodaßBilddatenzum Client ubertragenwerden,oderbeim Client lokal ablaufen(lokale 3DVisualisierung).In diesemFall werdeneinmaligdie GeometriedatenzumClient ubertragen.AuchdieVerteilungderRendering-PipelineaufmehrereRechneristmoglich.Die InteraktiongeschiehtuberAktionsnachrichten,diemit Hilfe einerVisualisierungsanwendung aufdie3DSzeneubertragenwerden,undanschließenderneuteBilderzeugung.DurchdieseinteraktiveRendering-Schleifeentstehtbeim Benutzerder EindruckeinerkontinuierlichenInteraktionmit der3D Szene.� Kommunikation: Hier wird zwischender KommunikationzwischenClient und DL-Serverzur Aushandlungvon Rechtenund lieferbarenObjektreprasentationen und der Kommuni-kation zwischenmehrerenBenutzernunterschieden.Der zweiteFall umfaßtAudio/Video-KonferenzenzwischenkooperierendenBenutzernund kann z.B. mit MBone-Tools un-abhangigvonderVisualisierungsanwendung realisiertwerden.DieserAspektsoll hierjedochnichtweiteruntersuchtwerden.Die KommunikationzwischenClientundServerwird jedocheinenwichtigenTeil derArchitekturSCA3Ddarstellenundin denweiterenKapitel genauerdiskutiert.

Von dengenanntenAspektenund Methodenzur UnterstutzungverteiltenArbeitensmit digi-talen3D Dokumentenwird in der weiterenArbeit vor allem der Punktinteraktive Visualisierungim Mittelpunkt stehenund untersuchtwerden.Retrieval mit Hilfe von metadaten-bzw. inhalts-basiertenVerfahrenund Audio/Video-Kommunikationwerdennur am Randeerwahnt,da diesePunktenicht zentralfur diewissenschaftlicheFragestellungderArbeit sind.

Anforderungenfur dasArbeiten mit digitalen Dokumentenin verteilten Informationsraumen

In Abbildung2.8ist einverteiltesSystemeinerDigitalenBibliothekskizziert.Mit demDL-System,dasDokumenteundDiensteverwaltetundanbietet,sindBenutzermit ihremComputerubereinTe-lekommunikationsnetzverbunden.Ihr Ziel ist dasinteraktive Arbeitenmit dendigitalen3D Doku-menteninnerhalbdesskizziertenInformationsraumes.In einemrealenDL-SystemsinddieAspekteSicherheit,BandbreitederAnbindungundLeistungderClient-Rechnerim Hinblick auf Hardwa-re und Software von großerBedeutung.DiesekritischenPunktesind in Abbildung 2.8 bei denjeweiligenKomponentendesGesamtsystemseingezeichnet.Die AnforderungenaneineSoftware-Architektur, diesichausdiesenAspektenergeben,sollennundiskutiertwerden.

Die Sicherheitsanforderungen, diefur diehieruntersuchteSoftware-Architekturhervorgehobenwerdensollen,sindderUrheberrechtsschutz(IPR: IntellectualPropertyRightsprotection), dieZu-griffskontrolle auf DokumenteamServer, die Integritat unddie Vertraulichkeit von Datenin demverteiltenSystemeinerDigitalenBibliothek. EineDiskussiondieserAspektewurdein Abschnitt


Abbildung2.8:SkizzierungeinerDL-Umgebungmit denkritischenAspekten

2.4vorgenommenundsoll anspatererStelleim BezugaufdienotwendigenMethodenin Kapitel3weitergefuhrt werden.Als AnforderunganeineSoftware-Architektursoll hier dieMoglichkeit zurBerucksichtigungdergenanntenSicherheitsaspektefestgehaltenwerden.

Da zur Ubertragungvon Dokumentenund zur Kommunikationein Netzwerkbenotigt wird,spieltdie Anbindungbzw. die verfugbareBandbreitezwischenServer undClient einegroßeRollefur dasGesamtsystem.An gleicherStellekannderdritte Aspekt,namlichdie lokaleLeistung,an-gesprochenwerden,dersichaufdiesehrunterschiedlicheLeistungvonComputernin heterogenenUmgebungenbezieht.Eine Anforderungan eineSoftware-Architektur, die dasverteilteArbeitenmit geschutztenDokumentenerlaubensoll, mußalsodie Anpassungsfahigkeit desSystemandieRandbedingungenwie Bandbreite(evtl. garantierteQualitat) undlokaleLeistungenthalten.

EinesolcheArchitektur, diemehrereBenutzersynchronisiertmit Informationenversorgenundsich an die BedingungeneineseinzelnenClients anpassensoll, muß uber eine Moglichkeit zurkontinuierlichenAuswertungder Gute einesClientsverfugen.DieseGute wird hier als skalarerWert mit Hilfe einerPerformanzmetrikbestimmtund beziehtsowohl die AnbindungalsauchdieVerarbeitungsleistungeinesBenutzerrechnersmit ein. Als globalesKriterium, dasoptimiert wer-densoll, kanndabeidie VerzogerungzwischenServer und Client wahrenddesArbeitensdienen.WeiterhinmussenParametergefundenwerden,die andie Randbedingungender jeweiligenSitua-tion angepaßtwerdenkonnen,um so optimaleBedingungenzu schaffen. DieseIdeewird in derSoftware-ArchitekturderSkalierbarenSzenenumgesetzt,die im Kapitel6 beschriebenwird.

Die AnforderungenaneineverteilteDL-Umgebung sollenhier nocheinmalzusammengefaßtwerden:� VerteilteVisualisierunggeschutzter3DDokumente: DadieDokumentezur3DVisualisierung

heutein vielenFallenauf die lokalenComputerubertragenwerdenmussenundgleichzeitigSicherheitsaspekte,wie Urheberrechte,berucksichtigtwerdensollen,mussenMoglichkeitenzurSicherungdieserDokumentein eineverteiltenVisualisierungs-Architektur integriertsein.� Dynamische Berucksichtigung von Anbindungund Leistungder Clienten: Um die Anpas-sungsfahigkeit derSoftware-ArchitekturandiejeweiligenRandbedingungeneinesBenutzerszu ermoglichen,mußeineGutemittelseinerPerformanzmetrikermitteltundim Systembe-kanntgemachtwerden.Die ArchitekturmußuberParameterverfugen,die fur die jeweiligeSituationoptimiert werdenkonnen.Im Fall der Software-ArchitekturSCA3D werdendie-seParametermit verschiedenenDokumentreprasentationen und derenAuflosungsgradver-knupft sein.DiesesKonzeptwird hier alsLevel-of-Informationbezeichnetund im weiterengenaueruntersucht.

Kapitel 3

Methoden

In diesemKapitel sollendie wichtigstenMethoden,die im Rahmender Arbeit benotigt werden,naherbeschriebenwerden.GrundlegendeMethodender3D Visualisierungin verteiltenUmgebun-genwerdenvorgestelltundTechnikenzurBildcodierungundUbertragungvoncodiertenBilddaten-stromenerlautert.WeiterhinwerdenMethodenzumEntwurfvonverteiltenSoftware-Architekturen,soweit siein derArbeit benotigt werden,beschrieben.

3.1 GeometrischeReprasentationenvon virtuellen 3D Objekten

Zunachstsoll genauerauf verschiedeneRepasentationsformenvon 3D Objektenin virtuelle Um-gebungeneingegangenwerden.Wie in Abschnitt2.3beschrieben,enthalten3D DokumentenebendenubergeordnetenStrukturinformationen(Szenengraph)unddenMaterialeigenschaften auchdeneigentlichengeometrischenInhalt,namlichdie verschiedenenObjekteeinerSzene.In diesemAb-schnittsollenMoglichkeitenfur die BeschreibungdergeometrischenParameterdieser3D Objekteerlautertwerden.Die wichtigstenundgebrauchlichstenReprasentationensindpolygonale3D Net-ze,parametrisierteKurvenbzw. FlachenundQuadricSurfaces, diemathematischexaktbeschreib-bareObjektedarstellen.In 3D Szenenkonnenjeweils verschiedeneBeschreibungsformenparal-lel benutztwerden.WeitereReprasentationenvon 3D Objekten,die durchKombinationenaus3Dund2D InformationenunterErhaltungwichtigerObjekteigenschaftenentstehen,werdenebenfallserlautert.Im folgendenwerdendieseHauptbeschreibungsarten vorgestelltundihreVor- undNach-teilediskutiert.Ein aktuellerUberblickderVerfahrenundReprasentationsformenvonOberflachenzurgeometrischenModellierungwird in HubeliundGross[HG00] gegeben.

3.1.1 Polygonale3D Netze

Polygonale3D NetzebestehenauseinemSatzvonverbundenenOberflachenelementen,die jeweilsvon PolygonenumfaßtwerdenundgemeinsameKantenaufweisen.Die PolygonesinddurchEck-punkte(Vertex) im dreidimensionalenRaumgegebenundweiseneinebestimmteUmlaufrichtungauf.JeweilszweiEckpunktesindentlangdesPolygonzugesdurcheineKante(Edge) verbunden.EsexistierenverschiedeneReprasentationsformenvon polygonalenNetzen,von denendie drei wich-tigstenhiergenanntwerdensollen.In Abbildung3.1sindsieanhandeinesDreiecksnetzesauszweiPolygonenillustriert.� ExpliziteBeschreibung: Hierbei werdenfur jedesPolygondie Eckpunkte�� !�#"%$ in Form

einerListe zusammengefaßt,wobeidie Reihenfolgeder EckpunkteentlangderKantendes

26

KAPITEL 3. METHODEN 27

Abbildung3.1:Beschreibungsformenfur polygonale3D Netze.

PolygonsderAnordnungin derListeentspricht.Zur SpeicherungvongroßenNetzenist die-sesVerfahrensehrspeicherintensiv, daEckpunktemehrfachgespeichertwerdenmussen.Esgibt auchkeinedirekteInformationubergemeinsameKantenundEckpunktevonPolygonen,wasdazufuhrenkann,daßbeimDarstellenauf demBildschirmKantenzweimalgezeichnetwerden.Vorteilebietetdieexplizite BeschreibungbeiderKonsistenzkontrollevonNetzen,dasievon denhier diskutiertenBeschreibungenammeistenInformationenthalt. In Abbildung3.1 ist aufderlinkenSeiteeinBeispielfur explizite Angabevon Polygonengezeigt.� Beschreibung durch Zeiger auf Eckpunktlisten: Bei dieserBeschreibungsformwerdenalleEckpunkteeinesNetzesin einergemeinsamenListe & erfaßt,wie in Abbildung3.1 in derMitte gezeigt.Ein Polygonwird durcheineListevon IndizesoderZeigernaufdieEckpunkt-liste definiert. In Abbildung 3.1 ist ')( durch die Eckpunkte &*( , &,+ und &.- gegeben.DieBeschreibung durchZeigerauf einenEckpunktlistehat gegenuberder expliziten Form dieVorteile,daßjederEckpunktnur einmalgespeichertwerdenmußunddaßKoordinatenvonEckpunktensehreinfachgeandertwerdenkonnen.Esist aberweiterhinschwierig,Polygonemit gemeinsamenKantenzu findenundgemeinsameKantenwerdenunterUmstandenauchnochdoppeltgezeichnet.� Beschreibung durch Zeiger auf Kantenlisten: Die Reprasentationvon PolygonnetzendurchZeigeraufKantenlistenverwendetebenfalls eineEckpunktliste& . Daruberhinauswird abereineKantenlistebenutzt,diefur jedeKanteAngabenuberdieEckpunkteunddiezugehorigenPolygonederKanteenthalt. Ein Polygonwird danndurcheineListe von Zeigernauf seine


jeweiligenKantenin derKantenlistedefiniert.Diesist in Abbildung3.1aufderrechtenSeitedargestellt.Polygonewerdendanndurchdie Zeichnungaller Kantendargestellt,wodurchkeinedoppeltgezeichnetenKantenmehrauftreten.

Ein wichtigerAspektfur polygonaleNetzeist die Uberprufbarkeit derKonsistenz,alsooballePolygonegeschlossensind,alle Eckpunktemindestenseinmalund nicht ofter als ein maximalerWert verwendetwerdenund ob jederEckpunktin mindestenszwei Kantenvorkommt.Weiterhinist essehroft wichtig, daßdasNetzkomplettverbundenist, daßestopologischplanarist undkeineLocheraufweist.DiesePunktemussenfur ein NetznachderErzeugungdurchgefuhrt werdenunderfordernje nachReprasenationsformeinenunterschiedlichenAufwand(siehehierzuin [FDFH90]Abschnitt:Consistencyof Polygon-MeshRepresentations).

3.1.2 Parametrisierte Kurvenund Flachen

Mit Polygonen,die stuckweiselineareApproximationenersterOrdnungan Flachendarstellen,konnennurebenfallsstuckweiselineareFlachenexaktdargestelltwerden.Fur alleanderenFlachenmussensehrgroßeMengenanStutzpunktenerzeugtund gespeichertwerden,um einezufrieden-stellendeGenauigkeit derApproximationzu gewahrleisten.Um ein in solcherWeisedargestelltesObjekt interaktiv verandernzu konnen,mussensehrviele Punkteangepaßtwerden,so daßdieentsprechendenOperationenrechenintesiv werden.Eine Alternative ist die Verwendungvon ma-thematischenFunktionenhohererOrdnung,mit denenKurvenundFlacheneffizienterangenahertwerdenkonnenunddie sichdaherbesserzur SpeicherungundManipulationeignen.Diessoll nunanhandvon Kurven im dreidimensionalenRaumerlautertwerden;Flachenstelleneine Genera-lisierungdesAnsatzesdar. Sehrhaufig werdenparametrisierteReprasentationenvon Kurven mitPolynomendritterOrdnungfur jedeKomponente� , � und " in derFormverwendet:

�/��0 $1� 2 � 043)576 � 0 + 58� � 0957: � � (3.1)�9��0 $1� 2�;�0 3 576<;=0 + 5>��;=0?5>:@;%�"A��0 $B� 2%CD0 3 576�CD0 + 5>�DCD0?5>:�CE� mit �GFH0�FI KubischePolynomewerdenverwendet,weil Funktionenmit geringererOrdnungkeineflexible

KontrollederForm einerKurve zulassenundFunktionenhohererOrdnungschnellsehrschwierigkontrollierbarwerden.ParametrischeKurve ersetztendenGebrauchder geometrischenSteigungvon Funktionen,die auchunendlichwerdenkann,durchdie VerwendungparametrisierterTangen-tenvektoren,die besserhandhabbarsind.Zur vollstandigenBestimmungeinerkubischenparame-trisiertenKurve sindvier bekannteGroßennotig. Dieskonnendie beidenEndpunkteeinerKurveund die jeweiligen Tangentenvektorenan denEndpunktensein,wie im Fall der Hermite-Kurven.NebendenHermite-Kurven sind auchdie Bezier-Kurven und die Splinessehrgebrauchlich,dieallesamtparametrisierteKurvenunterVerwendungkubischerPolynomedarstellenundsichin denAngabenderbekanntenRandbedingungenunterscheiden.WerdenKurvensegmenteJK��0 $ aneinan-dergefugt, soexistierenBedingungenfur die Randbedingungen,die entscheiden,in welcherFormdie Kurvensegmenteineinanderubergehen.Die wichtigstensind LNM (ein gemeinsamerEndpunkt),L ( (gemeinsamerEndpunkt,Tangentenvektorenin diesemPunktkollinearundmit gleicherLange),L + (gemeinsamerEndpunkt,Tangentenvektorenin diesemPunktkollinearundmit gleicherLange,zweiteAbleitung von Q(t) nacht am Uberganggleich) und O ( Kontinuitat ((gemeinsamerEnd-punkt,Tangentenvektorenin diesemPunktkollinear, abermit ungleicherLange)).


Fur ein Kurvensegment JK��0 $ kannmandasGleichungssystem3.1 folgendermaßenin Matri-zenschreibweiseausdrucken:

JP��0�$B� QSRTLJP��0�$B� U 0 3 0 + 0 �V

W XXXY2�� 2�; 2 C6#� 6#; 6 C�� ; � C:@� :@; : C

Z\[[[](3.2)

Die Koeffizientenmatrix L kann wiederumals Produkteiner GeometriematrixO und einerBasismatrix dargestelltwerden:JK��0 $)�_Q`R)^BR�O . Die Geometriematrixenthalt dabeidieviergeometrischenRandbedingungeneinerBeschreibungsform.� Hermite-Kurven: Ein Kurvensegmentin derHermite-Formwird durchdiebeidenEndpunkte'�( und 'a+ desSegmentesund durchdie Tangentenvektoren Qa( und Q*+ in denEndpunkten

beschrieben.DurchKontrollederEndpunkteundTangentenvektorenkanneinAnwenderdieKurvenformkontrollieren.� Bezier-Kurven: Bei derBezier-Form werdennebendenbeidenEndpunkten'�( und '�- nochweitereKontrollpunkte' + und ' 3 angegeben,die nicht auf derKurve selberliegenunddieTangentenvektoren'�( 'a+ bzw. ' 3 '�- in denEndpunktenfestlegen.� Splines: Splinesleitensichvon derz.B. im BootsbauverwendetenTechnikab,Metallstrei-fen bzw. HolzleistendurchKontrollpunktein eineglatteKurvenformzu bringen.Ein Splineist durchmehrereKurvensegmentedefiniert,diedurchjeweilsvier Kontrollpunktefestgelegtwerdenund derenUbergange L + -Kontinuitat aufweisen.Die Kontrollpunkteliegen dabeiim allgemeinennicht auf der Kurve. Mit uniformen,nicht-rationalenB-Splines(NURBS)konnenfolgendermaßenkontinuierlicheKurvenerzeugtwerden.Der ersteKurvenabschnittwird mit entsprechendenKontrollpunktenfestgelegt. Alle folgendenKurvensegmenteerhal-ten alsersteKontrollpunktedie letztendrei KontrollpunktedesvorhergehendenSegmentesund der letzteKontrollpunktkannfrei gewahlt werden.Die Kontrollpunktesind jeweils inderGeometriematrixO abgelegt. WeitereDetailszuSplinessindin [FDFH90]beschrieben.

3.1.3 Unterteilung von parametrisierten Kurvenund Flachen:SubdivisionSurfaces

Die Modellierungvon KurvenoderOberflachendurchverbundene,parametrisierteSegmentemiteinerfestenAnzahlvonKontrollpunktenermoglichteineAnnaherungmit bestimmterGenauigkeit.Wennbeim ModelliereneinebessereApproximationeinerangestrebtenKurvenformbzw. Ober-flachenformerzieltwerdensoll, sokanndiesdurcheinefeinereUnterteilungdesNetzesderKon-trollpunkteerreichtwerden.AuseinemBezier-Kurvensegment,dasdurchvier Kontrollpunktefest-gelegt ist, werdennun z.B. zwei Segmente,die insgesamtdurchsiebenKontrollpunktebestimmtsind,dasiesicheinenKontrollpunktteilen.DasselbePrinzipwird auchfur parametrisierteFlachenangewendet,umeinoptimalesKontrollnetzzuerhalten.In diesemFall sprichtmanvonSubdivisionSurfaces. DieseentstehendurchunendlicheVerfeinerungder ursprunglichenKontrollnetzedurchUnterteilungder Maschenund durchGlattung.Aus einemAusgangsnetzkonnendurchendlicheSchrittesehrguteAnnaherungenanFreiformobjekteerzieltwerden.


Abbildung3.2: ModellierungeinesObjektesdurchUnterteilungnachdemLoop-Schema(Abbil-dungaus[Gro98]).

Die beidenbekanntestenUnterteilungsverfahrenfur Flachenstammenvon Loop ([Loop87])undCatmull-Clark([CC78]). Loop-Subdivision-Surfaces arbeitenmit Dreiecksnetzen,wahrenddasCatmull-Clark-VerfahrenKontrollnetzemit rechteckigenMaschenverwendet.In Abbildung 3.2ist die schrittweiseApproximationeinesFreiformobjektesauseinemAusgangsnetzbestehendausmehrerenWurfelngezeigt(Abbildungaus[Gro98]). FastjedespolygonaleNetzkannalsKontroll-netzverwendetwerden,um ein Freiformobjektanzunahern.Die Bedingungen,die anein NetzfurLoop-Unterteilungsflachengestelltwerden,sindin [MH00] beschrieben.

3.1.4 Implizite Funktionsdarstellung: QuadricSurfaces

KurvenundFlachenkonnenalsLosungimpliziter GleichungenderFormb �� !�#"�$��c� (3.3)

modelliertwerden.Ein einfachesBeispielist eineKugelmit demRadius , derenOberflachedurch die Gleichung � + 5d� + 5e" +gf 8�h� beschriebenwird. Die Vorteile dieserDarstellungliegenin ihrergutenHandhabbarkeit, z.B. beidereinfachenBerechnungderOberflachennormalendurch U4ikji � �.ikji ; �.iji C V . Nachteiletretendadurchauf,daßesmehralsdiegewunschtenLosungenfur diegewahlteGleichunggebenkann,wie z.B. bei derModellierungeinerHalbkugel,wobeibestimmteRandbedingungeneingefuhrt werdenmussen,hier "mlS� .

Die allgemeineimplizite OberflachengleichungderForm:

b ��n� �o�#"�$)�p2�� + 5H6#� + 5>��" + 57qE:��A�r5>qts��."u5>q b �o"v5Hqxw��m5Hqty.�r5>q�z�"u57{P�c� (3.4)

definiert die Familie der Quadric Surfaces. Durch Wahl geeigneterKoeffizienten konnenvielfaltige Oberflachenmodelliertwerden,z.B. ergibt sich mit 2H�|6}�~�� f {H�� und ver-


schwindendenanderenKoeffizientendieobigeDarstellungderEinheitskugelim Ursprung.Weite-re VorteiledieserBeschreibungsformergebensichdurchMoglichkeitenfur effizienteTests,obeinPunktauf derOberflacheliegt, zur Berechnungvon " -Wertenbei gegebenem�n� � undzur Berech-nungvonSchnittenmit anderenFlachen.

3.1.5 Erweiterung von Objektr eprasentationen

Bei derVisualisierungvon3D SzenenwerdendieProzessederVisualisierungs-Pipeline, diesichjenachVisualisierungsverfahrenunterscheidenkann(siehe[FDFH90]:Kapitel IlluminationandSha-ding), schrittweisedurchgegangen.Als Eingabedient der Visualisierungs-Pipelinedie 3D Szene,die durchdie Szenengraphstruktur, die geometrischenParameterder jeweiligenObjektreprasenta-tion unddieMaterialeigenschaftenbeschriebenist. Die geometrischenParameterkonnendabeiim-plizit bzw. parametrischangegebenwerdenoderexplizit als3D NetzplanarerPolygone.Diese3DNetze(z.B.Dreiecksnetze)konnendurchverschiedeneVerfahren,wie 3D ScanningrealerObjekteoderTesselierungvon parametrisiertenOberflachen,erzeugtwordensein.NachdennotigenVi-sualisierungsschritten werdenBildobjektebzw. Bilddatenausgegeben,die eineVisualisierungder3D SzeneunterdenBedingungendesgewahltenBeleuchtungsmodellsundderKameraparameterdarstellen.

Bei der VisualisierungentstehenaberweitereReprasentationsformenvon Objekten,die zwi-schendervollstandigen3D Beschreibungundderresultierenden2D BeschreibungliegenundeinenunterschiedlichenGehaltan Informationuberdie Objekteenthalten.Prinzipiell werdenvom 3DModell bis zumvisualisiertenBild schrittweiseimmermehrexplizite ObjekteigenschaftenausderObjektreprasentationentfernt,sodaßObjekteim Bild mit ihrer semantischenBedeutungschließ-lich nurnochdurchdenmenschlichenWahrnehmungsapparatinterpretiertwerdenkonnen.Fur denBenutzer, der mit einer3D Szeneumgeht,hat diesnaturlich denVorteil, daßdie nicht direkt in-terpretierbarengeometrischenBeschreibungsformenvon Objektennun visuell verarbeitetwerdenkonnen.Aus verschiedenenGrunden,die hier vorallemdurchdenabgestuftenInformationsgehaltgegebensind, ist es aberauchvon Vorteil Objektreprasentationen zur Verfugungzu stellen,diezwischenderanalytischenbzw. numerischenBeschreibung unddervisuellenBeschreibung ange-siedeltsindundwahrendderVisualisierungalsZwischenprodukteanfallen.Bei der3D Visualisie-rungwird eineMerkmalsextraktion(Feature Extraction) fur die ObjekteeinerSzenedurchgefuhrt,diefur verschiedeneZweckegenutztwerdenkann.Als moglicheZwischenreprasentationenwerdenhier3D Netzemit verschiedenerAuflosung,Bounding-Box-Informationen, Konturenbzw. MaskenundTexturenvon Objektenangesehen.Diesekonnenwiederumkombiniertwerden,um neueBe-schreibungsformenzuerhalten,z.B.Bounding-Box-Informationen plusTexturen.DasZiel ist dabeidieErhaltungvonObjekteigenschaften,wahrendderexplizite InformationsgehaltderBeschreibungschrittweiseabnimmt(Level-of-Information).

In Abbildung3.3ist diesesKonzeptanhandvonzweiVisualisierungs-Pipelines dargestellt.AlsEingabeerhalt die erstePipelineein 3D Objektmit geometrischenParameternundMaterialeigen-schaften.Am EndederPipelinewerdenBilddatenauf demBildschirmoderalsDatenzur Weiter-verarbeitungausgegeben.WahrendderBearbeitungin derVisualisierungs-Ketteentstehenzusatzli-cheInformationenuberdieObjekte,diebeiBedarfseparatweiterverarbeitetwerdenkonnen.In derAbbildungsinddies3D Netze,Bounding-Box-Daten,BitmaskenundschließlichTexturen.Die Ob-jekteigenschaftenwerdenbeidieserAbfolgeteilweiseerhalten,sodaßsiedurchIntegrationin einezweiteVisualisierungs-Pipeline alsObjektvisualisiertwerdenkonnen.Der rechnerischeAufwandderVisualisierungkannauf dieseWeisein derzweitenPipelinean lokaleBedingungenangepaßtwerden.WeiterhinkonnenInformationen,diegeschutzt sind,durcheineveranderteBeschreibungs-


Abbildung3.3:ErweiterteRepasentationenzur Erhaltungvon ObjekteigenschaftenzwischenzweiVisualisierungs-Pipelines.

form von Objektenflexibel verwaltetwerden.Fur dasverteilteArbeitenmit 3D DokumentenbietetdiesesKonzeptabernochweitereVorteile,

daz.B. fur dasRetrieval von3D Objektenin verteiltenUmgebungenObjekteigenschaftenbenotigtwerden,die sich in Form von standardisierbarerMerkmalenin festgelegtenSchemataausdruckenlassen.In [PR99]werdenverschiedeneMerkmale,wie Volumen,Bounding-Box,Bounding-SphereundderTragheitstensorbezuglich einergeometrischenForm,zumAuffindenvon 3D ObjekteninverteiltenInformationsraumendiskutiert,die in den entstehendenMPEG-7Standard([ISO00a])eingehensollen.In [Loe00b] werdenvom Autor dervorliegedenArbeit Konturinformationenvon3D Objektenverwendet,um einenvisuellenIndex fur eine3D Datenbankzu erzeugen,der vonentferntenBenutzerzumRetrieval verwendetwird.

3.2 Digitale Bildsyntheseund interakti ve3D Visualisierung

Interaktive 3D Visualisierungbestehtim wesentlichauszwei Prozeßabfolgen,die in gegengesetz-ter Richtungzwischender3D SzeneundderBenutzerschnittstelleablaufen.Von derEingabeder3D Szenezur Benutzerschnittstelle, z.B. einemnicht-immersiven Display odereiner immersivenResponsiveWorkbench [GFG98], werdenentlangder Rendering-PipelineBilder erzeugt,die Er-gebnissederverwendetenBeleuchtungssimulation darstellen.DieseBilder werdenbeimBenutzerin dergewahltenFormangezeigt.EskonnennunAktionendurchdefinierteEingabenbezuglichdesvisuellwahrgenommenen3D Modellserzeugtwerden,diewiederumubereineProzeßabfolge,hierals Aktions-Pipelinebezeichnet,auf die eigentliche3D Szeneubertragenwerden.Durch erneuteVisualisierungerhalt der Benutzerein visuellesFeedbackbezuglich seinerAktionen,daser zuminteraktivenArbeitenmit der3D Szenebenotigt. Die beidenRichtungenderProzeßablaufesindin


Abbildung3.4skizziert.

Abbildung3.4:Visualisierungs-undAktions-PipelinebeiderinteraktivenVisualisierung.

EineallgemeineModellierungderDatenvisualisierungwird von HaberundMcNabb[HM90]angegeben,die folgendedrei Hauptkomponentenenthalt: Data Enrichement, VisualizationMap-ping und Rendering. Eine neuereTerminologiein [BDG98] benenntdiesedrei Prozesseals Da-tenfilterung(Filter), Datenabbildung(Map) und Darstellung(Render). Filterungmeint dabei,dieExtrahierungundAufbereitungvonRohdaten,z.B.AuswahlvonallenPunkteneiner3D Punktwol-ke, die zu einembestimmtenObjektgehoren,oderErmittlungeinerIso-Flachefur Volumendaten.Der nachsteSchritt,die Datenabbildung,erzeugtausdenangereichertenDateneinesogenanntesabstraktesvisuellesObjektAVO (Abstract Visual Object), dasausAttributen,wie z.B. Geometrie-elementenund Materialeigenschaften, besteht,die ausdenquantitativen EigenschaftenderDatenabgeleitetwerden.NachdiesemSchrittwird dasAVO durcheinenDarstellungsprozeßin einevomBenutzervisuell interpretierbareForm gebracht,alsoz.B. durcheine3D Rendering-PipelinealsBild aufeinemDisplayausgegeben.DiesedreiwichtigenSchrittesindin Abbildung3.5gezeigt.

Abbildung3.5:AllgemeinesVisualisierungsmodellnachHaberundMcNabb[HM90].

Die InteraktiondesBenutzermit denDatenkannnun an verschiedenenStellendesin Abbil-dung3.5angegebenenModellsstattfinden.Larkin et al. [LHG97] erlautern,daßInteraktiondurchdiedynamischeKontrollederProzesseFilter, MapundRenderdesobigenModellsermoglichtwird.Die vom BenutzerkontrolliertenParameterwerdenuberdieAktions-Pipeline(vgl. Abbildung3.4)andie jeweiligenProzesseubergebenunddamitauchauf die Datenreprasentationen angewendet.


In Abbildung 3.5 ist diesdurchPfeile mit der KennzeichnungInteraktion dargestellt.Ein Uber-blick uber interaktive geometrie-basierteVisualisierungskonzepte anhandder wissenschaftlichenLiteraturwird in Kapitel4 gegeben.

Ein kritischer Faktor bei der interaktiven Visualisierungist die Verzogerung,die durch diebenotigteZeitspannezurErzeugungundDarstellungneuerBilddatenbestimmtwird. DieserFaktorwird hierVisualisierungsverzogerung genannt.Die VerzogerungdurchdieErzeugung,UbertragungundAnwendungderAktionenaufdas3D Modell ist dagegengering,dakeinegroßenDatenmengenberechnetoderubertragenwerdenmussen.Diesgilt jedochnur, solangekeinekompliziertenMo-dellierschritteam3D Modell vorgenommenwerden,die wiederumzeitintensiv seinkonnen.Auchdie Filter- undMap-SchritteausAbbildung3.5 konnenim Falle der Interaktionzu einererhohtenVisualisierungsverzogerung beitragen.

Die Visualisierungsverzogerung wird stark durch das verwendeteBeleuchtungsmodellunddurchdie Bildauflosungbestimmt.Naturlich steigtdie Verzogerungstetsmit derKomplexitat der3D Szenenan,durchVerwendungverschiedenerBeleuchtungsmodellewerdenaberentscheidendeUnterschiedebeiderVerzogerungin einSystemeingefuhrt.Relativ einfache,lokaleBeleuchtungs-modellewie dasPhong-Shading[Pho75] sind zur interaktiven Visualisierunggut geeignet,weilsie eineminimaleVerzogerungbei ausreichenderBildqualitat ermoglichen.KomplexereglobaleBeleuchtungsmodelle,wie dasrekursive Raytracingoderdie Radiosity-Methode,bieteneinerea-listischeDarstellungsqualitat, sindaberaufgrunddeshohenbenotigtenZeitaufwandesfur die Be-rechnungeinesBildesfur die interaktive Visualisierungnur beschrankt einsetzbar. Die Radiosity-Methodeerlaubtallerdingsinteraktive Walkthroughsbei hoherQualitat, da die rechenintensivenSchritteim vorausdurchgefuhrt werdenkonnenund eineDarstellungder beleuchtetenSzeneer-zeugtwird, dieunabhangigvon Blickposition-undwinkel ist.

3.2.1 Die Rendering-Pipeline

Der Prozeßder Bildsynthesefur ein gegebenesdigitales3D Modell wird durch die Rendering-Pipelinebeschrieben.Eine wichtige Komponenteder Rendering-Pipelineist die Beleuchtungssi-mulation,jedochmussenweitereSchrittezurVisualisierungeinervirtuellen3D Szenedurchgefuhrtwerden.In Abhangigkeit vom gewahltenRendering-Algorithmuskanndie Rendering-Pipelineun-terschiedlichaufgebautsein.Ein Vergleichhierzuist in [FDFH90] zu finden.In Abbildung3.6 isteinBeispieleinerRendering-Pipelinegezeigt,fur dasim folgendeneineallgemeineDiskussionderEinzelkomponentendurchgefuhrt wird.

Als EingabedientderRendering-Pipelineeine3D Szene,die aus3D Objektenmit ihrengeo-metrischenParameternundMaterialeigenschaften,LichtquellenundmindestenseinerKameraein-stellungbesteht.DieseEingabeszenekanndurchein Modellierwerkzeugoderdurch3D Scanningentstandenseinundliegt in FormeinerSzenenbeschreibungbzw. einerSzenendatenbankvor.

Beim Szenendurchgang(scenetraversal) wird der strukturelleAufbau der Szeneerfaßt,umTransformationender Objekte,wie Translation,Rotationund Skalierung,aufzulosen.Dabeiwer-dendieObjekteausihremlokalenKoordinatensystem,in demsiemodelliertwurden,in dasglobaleWeltkoordinatensystem transformiert,in demdie gesamteBeleuchtungsberechnung durchgefuhrtwird. Im nachstenSchrittwird mit Hilfe derKameraeinstellungeineeinfacheEinteilungderSzenein relevanteObjekteundnicht-relevanteObjekte,diehinterdemBeobachterliegen,vorgenommen,um die Szenenkomplexitat zu vermindern(Annahme/Ablehnung). Fur lokale Beleuchtungsmo-delle ist dieserVorgangproblemlosmoglich, fur eine globaleBeleuchtungssimulationmit demRaytracing-oderRadiosity-VerfahrenmusseneventuellauchMehrfachreflexionenberucksichtigtwerden,dieEinflusseausdemBereichhinterdemBeobachterim Ergebnissichtbarmachen.Im An-


Abbildung3.6:Rendering-Pipeline.

schlußandiesenSchrittfolgt dieBeleuchtungssimulation, welcheeinemoglichstguteBerechnungder Lichtausbreitungin dembeschriebenengeometrischenRaumliefern soll. DurchVerwendungvon Raytracing-bzw. Radiosity-VerfahrenkonnensehrrealistischeDarstellungenderBeleuchtungerreichtwerden,jedochsteigtauchderAufwandmit dererreichtenQualitat starkan.In denuntenfolgendenAbschnittenwerdenlokaleundglobaleBeleuchtungsmodellenaherbesprochen.

Bei derfolgendenKameratransformation wird die gesamte3D Szenein dasKoordinatensy-stemderKameraabgebildet.Beim sogenanntenClipping werdennunalle EckpunktedesModellsentfernt,die nicht im Blickfeld (viewing frustrum) liegen.DasBlickfeld ist durchdie Kameraposi-tion, dieBlickrichtungunddieOffnungswinkel bestimmt.DurchProjektionderverbleibendenKo-ordinatenpunkteaufdasFensterdesAnzeigegeratesbzw. denViewport derAnwendung(3D View-port Projektion) werdendieBerechnungenim dreidimensionalenRaumabgeschlossen.Der letzteSchritt der Bildschirmrasterung bestimmtfur jedenPixel desGeratedisplaysdasentsprechendegeometrischePrimitiv ausden vorhergehendenTransformationenund ermittelt den zugehorigenFarbwert.Somitenstehtin diesemSchrittdaseigentlicheBild auf demBildschirm.Die Farbwertefur jedenBildpunkt wurdenentwedermit derBeleuchtungssimulationbestimmtoderwerdenauseinemTexturbild entnommen(texture mapping).

Die genanntenSchrittederRendering-Pipelinewerdenentwedermit Hardware-oderSoftware-Komponentendurchgefuhrt. Hochleistungsrechnerfur Graphikanwendungenbietenoft einekom-pletteHardware-unterstutzteRendering-Pipeline.Jedochwird durchdie schnelleEntwicklungderRechenleistungvon modernenMikroprozessoreneine vollstandigeAusfuhrungdurch Software-Komponentenfur breiteAnwendungsfelderimmerrealistischer.

3.2.2 Lokale Beleuchtungssimulation

BeieinemlokalemBeleuchtungsmodellhangendieberechnetenIntensitatenaneinemOberflachen-punktnur von denlokalenOberflachen-undMaterialeigenschaften unddenbeleuchtendenLicht-quellenab. Um die Beleuchtungeiner3D Szenezu simulierenwird die gesamteLichtintensitatberechnet,die in dieRichtungdesBeobachtersreflektiertwird. Die Gesamtintensitat setztsichauseinemdiffusen,einemspekularenundeinemambientenAnteil zusammen,d.h. ��e� i 5S�=�/5H�� .Die Reflexion von Licht anOberflachenkannphysikalischdurchdiesespiegelnden(spekular)unddiffusenAnteile beschriebenwerden.Der diffuse Anteil hangtnur von der Intensitat und Rich-


tungdesLichteinfalls ab,wahrender von derBeobachtungsrichtung unabhangigist. Dieswird imGesetzvon Lambertausgedruckt. Es besagt,daßder BetragdesreflektiertenLichtintensitat pro-portionalzumCosinusdesWinkels � zwischenOberflachennormalen� undLichteinfallsrichtung�

ist. In Abbildung 3.7 wird der Zusammenhangverdeutlicht.Fur Winkel großer �E� Gradwirddie Intensitat theoretischnegativ. Da dies aberphysikalischnicht sinnvoll ist, werdennur Win-kel zwischen� und �E� Gradeinbezogen.Fur alle anderenFalle insbesondereauchum indirekteBeleuchtungannaherungsweisezu simulieren,wird ein konstanterTerm eingefuhrt, der in einerambientenGrundintensitat resultiert.

Abbildung3.7:LokaleBeleuchtungssimulationmit spekularemAnteil.

Um spiegelndeReflexion, alsoSpiegelungenund Highlights, simulierenzu konnenwird derspekulareAnteil in der Gesamtintensitat mit Hilfe der Phong-Approximation[Pho75] berechnet.SpiegelndeReflexion hangtim Gegensatzzur diffusenReflexion von derBlickrichtungdesBeob-achtersab. DirekteSpiegelungundHighlightskonneninnerhalbdesWinkelbereichseinesKonusum die Hauptreflexionsrichtung� beobachtetwerden(sieheAbbildung3.7).JenachMaterial istdieserKonusengeroderweiter. In Hauptreflexionsrichtungergibt sichdie maximaleIntensitat derReflexion, wahrendnachPhongdie Intensitat mit der � -tenPotenzdesCosinusdesOffnungswin-kels � desKonusabnimmt.Der Potenzwert� unterscheidetdie verschiedenenspekularenReflexi-onseigenschaftenderverwendetenvirtuellenMaterialien.

Die vollstandigeGleichungzur Berechnungder Gesamtintensitat kann nun folgendermaßenformuliertwerden,indemdiediffusen,spekularenundambientenTeileverwendetwerden:

�D�� <� ��{@�=� �#��k�� o5 � ��( �D� ��{ in�D�@� ��A57{��#��t� ��$ (3.5)

In Formel3.5druckendieKoeffizienten{@� , {%� und { i jeweilsdieambienten,diffusenundspe-kularenReflexionseigenschaftenderMaterialienaus.Die Intensitaten�D� und � �#��k�� stehenfur dieeinfallendenIntensitatenaller relevantenLichtquellenbzw. dieambienteLichtintensitat, wobeidie


letzterehiernureineungenaueApproximationist.DieseGleichungzur lokalenBeleuchtungssimu-lation eignetsichauchfur denEinsatzin interaktiven Visualisierungsanwendungen, danur relativwenigeBerechnungsschrittepro geometrischemPrimitiv ausgefuhrt werdenmussen.Nachteileer-gebensich durchdie mangelndeRealitatsnaheder erzeugtenBilder der 3D Szene,insbesondereSchatten,MehrfachreflexionenunddurchscheinendeMaterialienkonnennicht odernur alszusatz-licherEffekt dargestelltwerden.

3.2.3 GlobaleBeleuchtungssimulation

Um einegroßereRealitatsnahedererzeugtenBilder einerbeleuchteten3D Szenezu ermoglichen,mussenVerfahrenzur Berucksichtigungvon Mehrfachreflexionenzwischenallen ObjekteneinerSzeneverwendetwerden.DiesfuhrtzueinemstarkenAnwachsendesBerechnungsaufwandes, laßtaberaucheineSimulationvielerphysikalischerPrinzipienderLichtausbreitungzu.Die wichtigstenVerfahrenzur globalenBeleuchtungssimulation sind dasrekursive Ray-Tracing,bei dem Strah-len durchdie Szeneverfolgt werden,unddasRadiosity-Verfahren,dasein GleichungssystemzurBerechnungdesEnergieflusseszwischendiffus reflektierendenOberflachenelementenunterAn-nahmeder Energieerhaltunglost,um die Beleuchtungsverhaltnisse zu ermitteln.BeideVerfahrenliefernsehrrealistischeErgebnisse,wobeiteilweiseeinsehrhoherZeitaufwandundbestimmteBe-schrankungenhinsichtlichderDarstellungfur diebeidenVerfahrenheutenochunumganglichsind.

Ray-Tracing

Die globaleBeleuchtungssimulationmittels Strahlverfolgung(Ray Tracing) wurdeerstmalsvonWhitted [Whi98] realisiertund beschrieben.Beim rekursiven Ray-Tracing wird der fotographi-scheProzeßumgekehrt,derin derStrahlenoptikdurcheineAusbreitungvon LichtstrahlenvonderQuelleuberMehrfachreflektionenzumBeobachterauge,demSensor, beschriebenwird. BeimRay-TracingwerdenStrahlenvom Blickpunkt durchdie Bildschirmebenein die 3D Szenegeschossenundihr Weg dortdurchMehrfachreflexion weiterverfolgt.

EinEinzelstrahl,dervomBeobachtungspunktdurcheinenBildschirmpixel in dieSzeneverfolgtwird, wird auf seinenerstenSchnittpunktmit einemObjektder3D Szenehin untersucht.Trifft erkein Objekt, so wird der FarbwertdesPixels auf die Hintergrundfarbegesetzt.WennjedocheinSchnittpunktgefundenwird, sowerdenvon diesemOberflachenpunktdesObjektesweitereStrah-len in die Szenegeschicktundweiterverfolgt. Am Schnittpunktwerdenalle zuruckgeliefertenIn-tensitatender Nachfolgestrahlenaufsummiert,um die Gesamtintensitat und damit den Farbwertfur denBildpunktzuberechnen.DurchunterschiedlicheStrahltypenkonnenbestimmteEffektederLichtausbreitungsimuliertwerden.DurchVerfolgungvon Strahlendirekt zu denLichtquellenderSzene,kannderdirekteEinflußderLichtquellenberucksichtigtwerden.Dieserwird dannwie imvorigenAbschnittbesprochennachdemLambert’schenGesetzerrechnet.DurchUntersuchungdie-serStrahlenaufSchnittpunktemit anderenObjekten,konnenSchatteneffekteberucksichtigtwerden(shadowrays). AuchspekulareEffektekonnenaufdieseWeiseermitteltwerden.

Um die diffuseReflexion zu berechnen,werdenvom erstenSchnittpunktin alle Richtungeninnerhalbder oberenHemisphareNachfolgestrahlenverteilt. Es existierenverschiedeneAnsatzezuVerteilungderStrahlen,diez.B.dieMonte-Carlo-Verteilungverwenden.Die Nachfolgestrahlenwerdendannauf neueSchnittpunktemit anderenObjektenuntersucht,um andiesenSchnittpunk-tendenobenbeschriebenenAufsummierungsprozeßderLichteffektedurchzufuhren.DurchRuck-meldungdesIntensitatswertesandie jeweils letzteRekursionsstufewird die Gesamtintensitat amerstenObjektschnittpunktsehrgenauermittelt. In Abbildung3.8 ist dieserProzeßdesrekursiven


Ray-TracinganhandeinerSzenemit zweiObjektenundeinerLichtquelledargestellt.

Abbildung3.8:GlobaleBeleuchtungssimulationdurchrekursivesRay-Tracing.

Objekt ist dabeiteilweisetransparentund laßteineTransmissionQ von einfallendenLicht-strahlenzu. In derVergroßerungdesSchnittpunktesim unterenAbbildungsbereichist die Strahl-verteilungin die oberhalbdesOberflachenpunktesliegendeHemisphareverdeutlicht.Die diffusenAnteile werdendurcheinegleichmaßigeVerteilungvon Strahlen�� simuliert,wahrendderspie-gelndreflektierendeAnteil durchdiePhong-Approximationermitteltwird.

Mit Hilfe desphysikalischenGesetzesvon SnelliuskannanSchnittpunktennunauchdie opti-scheBrechungvonLichtstrahlenanteilweisetransparentenObjektenberechnetwerden.DasGesetzvon Snelliussagtaus,daßLichtstrahlenbeim Ubergangvon einemMediummit Dichte � ( in einMedium mit Dichte �D+ teilweisereflektiertwerdenund sich teilweisedurchdaszweiteMediumweiterausbreiten(Refraktion).Die reflektiertebzw. refraktierteIntensitat hangtvondemVerhaltnisderBrechungsindizes�/( und �?+ ab,undweiterhinvom Einfallswinkel desLichtstrahls.Wenn ��(der Winkel zwischenEinfallsrichtungund Oberflachennormalein Medium ist, und ��+ der Win-kel zwischenTransmissionrichtungund Oberflachennormalein Medium zwei ist, danngilt nachSnellius:

�/( �� (��_�?+ �� a+ (3.6)

Der rekursive Prozesse,derzur SummierungallerEffektebei derLichtausbreitungfuhrt, kannaufverschiedeneWeiseabgeschlossenwerden.EntwederwenneinebestimmteStufederRekursion


erreichtist, kein Objektmehrgeschnittenwird oderderBeitrageinesObjektesuntereinekritischeSchwellefallt, wird die Rekursionabgebrochenund die Gesamtintensitat fur denentsprechendenBildpunkt aufsummiert.Gleichung3.7 gibt die Beleuchtungsformelfur dasRaytracing-Verfahrenan,wobeidie reflektiertenundtransmittiertenAnteilederIntensitat durch {%��=� bzw. { � � � beschrie-benwerden.Fur eineweitergehendenDiskussionsiehe[Gla99].

�D�� <� ��{@�� #��k�� !57{ i � �k��( �D� �D�@� ��A57{��#�=��57{ � � � (3.7)

Der rechnerischeHauptaufwandbeimRay-Tracingliegt in derBerechnungderSchnittpunktezwischenLichtstrahlenundObjekten.DaherwurdeVerfahrenzur optimalenSzenenstrukturierungundmoglichsteffizientenSchnittpunktberechnung entwickelt, die zuersteinfacheOberflachenfor-menvon Wurfeln oderKugelnauf Schnittpunktetesten,ehedie darin eingeschlossenenObjektederSzeneuntersuchtwerden.Dadurchkonnendie Berechnungszeitenfur ein Bild starkreduziertwerden(siehehierzu[MF99]).

DasRay-Tracing-VerfahrenerzeugtDarstellungenderbeleuchtetenSzenemit bestimmtenCha-rakteristiken. Die Schattenbildungin der Szeneist sehrhart, da eineLichtquellevon einembe-stimmtenOberflachenpunktausvoll sichtbarist und fur denNachbarpunktschonganzverdecktseinkanndurchein anderesObjekt.WeicheUbergangevon hell nachdunkel sindnur schwerzuerreichen.Durchdie VerwendungdesPhong-Shadingerhaltendie Oberflachenin densimuliertenBildernoft einErscheinungsbild,dasanPlastikobjekteerinnert.

Die Radiosity-Methode

Der Begriff Radiositybezeichnetbei diesemVerfahrendenStrahlungsenergieflußpro Flachenein-heit i� i�¡ einerObjektoberflache.Die globaleBeleuchtungwird durchdie ErmittelungdesStrah-lungsenergieflussesim Gleichgewicht zwischenallendiffusenOberflacheneiner3D Szeneberech-net.DurchdieseMethodewerdenrealistischeDarstellungenderBeleuchtungssituation in Szenenerzielt,wobei im GegensatzzumRay-TracingweicheSchattenubergangeermoglicht werden.DasRadiosity-VerfahrenwurdeausphysikalischenSimulationsmethodenfur denStrahlungsenergieflußin geschlossenenSystemenfur computergraphischeZweckeweiterentwickelt. Die erstenAlgorith-menzur globalenBeleuchtungssimulationwurdenvon Goral et. al. [GTGB84] und Nishita undNakamae[NN85] vorgestellt.

DaeinBerechnungdesEnergieflusseszwischenallenOberflachenpunktenzuaufwendigware,werdendieObjektemit einemNetzvonplanarenOberflachenelementen(patches) uberzogen.DieseOberflachenelementestellenLambert’scheReflektorendar, sodaßnurdiffuseReflexion betrachtetwird. Lichtquellenwerdenals emittierendeOberflachenelementedargestellt.Durch dieseVerein-fachunglaßtsich mit Hilfe der Radiosity-MethodeeineDarstellungder beleuchteten3D Szenenim Objektraumerzeugen,die unabhangigvom Blickpunkt ist. Mit dieserMethodelassensichalsointeraktive Walkthroughsrealisieren,dader rechenintensive Beleuchtungsschrittim vorausdurch-gefuhrt werdenkann.Bei der interaktiven Visualisierungwird die Rendering-PipelinedannunterVerwendungdieserReprasentationderbeleuchteten3D Szenedurchlaufen.Die Radiosity-Methodestellt,wie dasRay-Tracing,einesehrzeitaufwendigeLosungfur die globaleBeleuchtungssimula-tion dar. Die rechnerischHauptarbeitliegt in derErmittelungderFormfaktorenfur einegegebeneSzene.EineweiterfuhrendeDiskussionhierarchischerRadiosity-Methodenist beiSchafer[Sch00]zufinden


3.3 Verteilte, objekt-orientierte Systeme

In diesemAbschnittwerdenGrundlagenobjekt-orientierter, verteilterSystemebesprochen,diezumEntwurf einerSoftware-Architekturim BereichDigitaler Bibliotheken benotigt werden.VerteilteSystemeim UmfeldderInformationsverarbeitung bestehenausmehrereneigenstandigenRechnern,die uberein Kommunikationsnetzwerkmiteinanderkooperieren,umein festgelegtesgemeinsamesZiel zu erreichen.Die UmsetzungverteilterSystemeerfolgt ambestenin einerobjekt-orientiertenSprache,die die Vorteile der Kapselungund wohl definierterMethodenschnittstellen bietet. Imfolgendenwerdenzuerstdie EigenschaftensolcherSystemevorgestellt,dannfolgt die Beschrei-bungdesobjekt-orientiertenModellsundabschließendwerdenVerteilungsplattformen,sogenannteMiddleware, amBeispieldesIndustriestandardsCORBA [OMG98] diskutiert.

3.3.1 Eigenschaftenverteilter Systeme

Ein verteiltesSystembestehtauseinerMengevon verteilten,kooperierendenKomponenten.DieKooperationderverschiedenenKomponentenwird uberdenAustauschvonNachrichtenmittelsei-nesKommunikationsnetzwerkesrealisiert.DieseNachrichtenwerdenzurSynchronisationderver-teiltenProzesseundzumDatenaustauschverwendet.NebendenProzessen,die auf verschiedenenRechnernarbeiten,konnenauchdieDateneinerAnwendungverteilt sein,indemsiez.B.aufgeteiltauf verschiedeneDatenbanken im Gesamtsystemvorliegen.SchließlichkonnenauchmehrereBe-nutzergleichzeitigmit einemverteiltenSystemarbeiten,indemsie Teile desGesamtsystemsaufihremRechnerbetreiben.In diesemFall sprichtmanvonverteiltenBenutzern.

ManunterscheidetdiephysikalischeSichtaufeinverteiltesSystem,diedessentechnischeRea-lisierungmit denbeteiligtenRechnernals KnoteneinesKommunikationsnetzwerkes und die Ei-genschaftendesNetzwerkesselbstbeschreibt.Im Gegensatzdazubeschreibtdie logischeSichtdieAnwendungsaspekte,diedurchdieVerteilungvonZustand(Daten)undVerhalten(Programmcode)bestimmtwerden(siehe[CDK94]). In denProzessensindTeile desZustandesunddesVerhaltensgekapselt.In Abbildung3.9 ist die StruktureinesverteiltenSystemsausvier RechnernundeinemverbindendenNetzwerksgezeigt.

VerteilteSystemeweisenwichtigeVorteileaberauchNachteilegegenuberzentralorganisier-ten Systemenauf. Die Vorteile reichenvon großererWirtschaftlichkeit durchein besseresPreis-Leistungs-Verhaltnis von kleineren,vernetztenRechnern,uber eineerhohte Verfugbarkeit durchmoglicheRedundanz,bessereSkalierbarkeit durchErweiterbarkeit, bis hin zu Geschwindigkeits-vorteilendurchParallelisierungvon Programmteilen.MoglicheNachteileentstehendurchdie Of-fenheit,Komplexitat undHeterogenitat vonverteiltenSystemen,dennhierdurchnimmtdieAnzahlpotentiellerFehlerquellenzu,diedie Funktionsfahigkeit desGesamtsystemsbeeintrachtigenkann.AußerdemwerdenAngriffspunktein einemsolchenSystemleichterauszumachenundzuerreichensein,sodaßSicherheitsaspekteeinebesondereBedeutungbekommen.Die Heterogenitat erfordertin einemhohenMaßeMechanismenzurIntegrationverschiedenerTechnologienin einemverteiltenSystem,z.B. konnenverschiedeneBetriebssystemeundProgrammiersprachenin verteiltenSyste-mengleichzeitigzum Einsatzkommen.Weiterhinkanndie Kommunikationdurcheineschlech-te Netzverbindungverlangsamtwerden,sodaßengzusammenarbeitendeKomponentenmoglichstnicht verteilt werdensollten.In Tabelle3.1sinddie Vor- undNachteilenocheinmalin einerUber-sichtzusammengefaßt.


Abbildung3.9:AufbaueinesverteiltenSystemsmit AustauschvonNachrichten.

Merkmal ZentralesSystem VerteiltesSystemWirtschaftlichkeit gering hochVerfugbarkeit gering hochSkalierbarkeit schlecht gutKomplexitat gering hochKonsistenz einfach schwierigSicherheit hoch geringTechnologie einheitlich heterogen

Tabelle3.1:Vor- undNachteileverteilterSystemegegenuberzentralenSystemen.

Transparenz

Um dieKomplexitat einesverteiltenSystemsfur denAnwendungsprogrammiererunddenAnwen-derzu verbergen,werdenim allgemeinenForderungennachTransparenzhinsichtlichbestimmterMerkmalegestellt.DasZiel ist dabei,die Verteiltheitgewissermaßendurchsichtigzu machenunddasSystemalszentralisierteserscheinenzu lassen.Dadurchwird derUmgangmit derVerteiltheiteinessolchenSystemserleichtert.Die wichtigstenKriterien fur die Transparenzgefordertwird,sind:� Ortstransparenz: Der physischeOrt einerKomponentemußnicht bekanntsein,um auf sie

zugreifenzukonnen.� Zugriffstransparenz: Auf lokaleundentfernteKomponentenwird auf identischeWeisezuge-griffen.


� Ausfalltransparenz: Fur denBenutzerist derAusfall einerKomponentetransparent.� Technologie-Transparenz: Die Verwendungvon unterschiedlichenTechnologienwird vordemAnwenderverborgen.� Concurrency-Transparenz: Beim Zugriff mehrererBenutzerauf eineKomponenteist diesegemeinsameNutzungnichterkennbar.

Die RealisierungdieserTransparenzkriterienmachteinengroßenTeil der Komplexitat der inverteiltenSystemenbenotigtenMechanismenaus.

Client/Server-Modell

DurchdasClient/Server-Modell werdenzwei verschiedeneRolleneingefuhrt, die von Komponen-tenbzw. Prozessenin einemverteiltenSystemeingenommenwerdenkonnen.Dabeiwird ein Me-chanismuszur Kommunikationvorrausgesetzt,der synchronund auftrags-orientiertist, d.h. dereineNachrichtsendendeProzeßbleibt inaktiv, solangeer keineAntwort auf seineAuftrag bekom-menhat.DieseArt desKommunikationsmechanismuswird auchalsRemote-Procedure-Call (RPC)bezeichnetundunterscheideteinenSender, einenEmpfanger, eineAuftragsnachrichtundeineEr-gebnisnachricht(siehe[CDK94]).

Die Rollen desClientenim Client/Server-Modell ist die einesDienstnutzers,der einenRPCauslostunddamitdenServerauffordert,diebei ihm implementierteProzedurmit denubergebenenEingabeparameternauszufuhren.Der Server alsDiensterbringersendetdanndie Antwortnachrichtmit denErgebnissender Prozeduran denAuftraggeberzuruck. In verteiltenSystemen,die nachdem Client/Server-Modell arbeiten,konnenProzesseauchgleichzeitigdie Rolle einesClientenbzw. einesServersannehmen,wennz.B. ein Server eineAnfrageaneinenuntergeordnetenServerweiterleitet.

Bei VerwendungdiesesKommunikationsmodellskonnenverschiedeneArten von Fehlernauf-treten.Zum einenkonnenNachrichtenbei der Ubertragungverlorengehen,zum anderenkanneszuAusfallenvonProzessendurchAbsturzkommen.ManunterscheidetzwischenVerlustvonAuf-tragsnachrichtbzw. Ergebnisnachrichtund Ausfall von Server- bzw. Client-Prozeß.Je nachdemwelcheDienstgute von einerAnwendungerwartetwird, werdenverschiedeneVermeidungsstrate-gien gegenuberdiesenFehlernbenotigt. Idealerweisesollte eineAnwendungerwarten,daßauchbeim Auftreten von Fehlernein Auftrag genaueinmal ausgefuhrt wird und genauein Ergebniszuruckgeliefertwird (Exactly-Once-Strategie [VY99]). Dieseinzuhaltenist in einemverteiltenSy-stemjedochnicht immermoglich.Fur niedrigereDienstguteanforderungenexistierenverschiedeneandereStrategien,diezumindesteinenTeilerfolggarantieren.

3.3.2 VerwendungeinesObjektmodelles

Um die Komplexitat einesverteiltenSystemsmoglichstgut bewaltigenzu konnenund effizienteMittel zur RealisierungsolcherSystemezu erhalten,bietetsichdie VerwendungeinesObjektmo-dellsfur denEntwurfundeinerobjekt-orientiertenProgrammiersprachefur dieEntwicklungan.Imfolgendenwerdendie EigenschaftendesObjektmodellsund einein objekt-orientiertenSystemenverwendeteTerminologieerlautert.

Zur systematischenStrukturierungeinesallgemeinenProblemraumesbeschreibtein Modell,nachwelchenPrinzipiendiegewahlteDarstellungbeiderModellierungerzeugtwird. Zur Struktu-rierungverteilterinformationstechnischer Systeme,die schondurchihre Großeunddurchdie ho-henAnforderungenanihreFunktionalitat komplex sind,wird oft einObjektmodellverwendet.Das


Objektmodellbenutztdie KonzepteAbstraktion,Modularitat, KapselungundHierarchie,um einesystematischeDarstellungdesverteiltenSystemszu erlauben.EinetiefgehendeDiskussiondieserBegriffe unddesEntwurfsobjekt-orientierterSystemeist in Boochet al. [BMN99] zufinden.� Abstraktion: Eine VereinfachungdesSystemsdurchHervorhebung relevanterAspekteund

Vernachlassigungnicht-relevanterAspekteerlaubtdie ReduzierungderKomplexitat, indemeinegrobereaußereSichtverwendetwird. Die Auswahl derrelevantenAspektefur die Ab-straktionist dabeisubjektiv. Außerdemliefert die Abstraktioneine Terminologiezur Be-schreibungdesSystems.� Modularitat: Mit Modularitat ist dieUnterteilungdesProblembereichsbzw. Systemsin Teil-bereichegemeint,die denrelevantenAspektenderAbstraktionentsprechen.Weiterhinwer-dendamitwohl definierteGrenzenzwischendenTeilbereichengefordert.� Kapselung: Alle Details,dienichtalsrelevantfur die außereSichtbetrachtetwerden,werdeninnerhalbderBereichsgrenzengekapselt.DurchdieKapselungwird eineinnereSichtaufdieImplementierungeinesSystembereichsermoglicht unddie außereSicht implementierungs-unabhangiggehalten.Die Grenzenbzw. wohl definiertenSchnittstellenwerdenzumZugriffaufdiegekapseltenDetailsgenutzt.� Hierarchie: DiesesKonzepterlaubtdieBeschreibungvonBeziehungenzwischenverschiede-nenAbstraktionen.BekannteHierarchienim Objektmodellsinddie Spezialisierung(ausge-drucktdurchis-a) unddieAggregation(ausgedruckt durchpart-of) vonzweiAbstraktionen.Spezialisierungbedeutet,daßeineAbstraktionalle Eigenschaftender zweitenAbstraktionbesitzt(z.B.

”Ein Hammerist ein Werkzeug“ ). Aggregationbedeutet,daßeineAbstraktion

sich bei ihrer Definition auf einezweiteAbstraktionbeziehenkann(z.B.”Ein Stiel ist Teil

einesHammers.“ ).

Die Verwendungdieservier Konzeptezur DarstellungeinesSystemserlaubtseineStrukturie-rung,wodurchdie Komplexitat fur denBetrachterreduziertwird. Die Modellierungist abhangigvon der subjektiven Auswahl der relevantenAspekte,daherist auf dieseWeisekeinekanonischeDarstellungsweisemoglich.Dies ist aberfur denEntwurf unddie UmsetzungeinesverteiltenSy-stemsauchnichtnotwendiggefordert.

Terminologieobjekt-orientierter Systeme

In diesemAbschnittwerdendiewichtigstenBegriffe erlautert,die im Umgangmit demObjektmo-dell benotigt werden.Zuerstwird derBegriff desObjektesim ZusammenhangdesObjektmodellsdiskutiert,danachwird auf denAustauschvon Nachrichtenunddie Klassifizierungvon ObjektennachTypeneingegangen.� Objekt: DerBegriff desObjektesist,wie derNameschonandeutet,zentralfur dasObjektmo-

dell. DurchAnwendungder KonzepteAbstraktion,Modularitat, Kapselungund Hierarchiewird dasSystemals Mengevon Objektenmodelliert.Durch die Abgrenzungder Objektemittels wohl definierterSchnittstellenwird die geforderteModularitat erreicht.Durch denAbstraktionsgradwird dieGranularitat derModellierungmit Objektenbestimmt.

JedesObjekteinesSystemshat eineeindeutigeIdentit at, so daßesmittelseinerReferenzadressierbarundzugreifbarist. Weiterhinwird einObjektdurcheinenZustand undeinVer-


halten festgelegt, diezusammendieFunktionalitat desObjektesdefinieren.DerZustandent-sprichtin einerobjekt-orientiertenAnwendungdengekapseltenDaten,wahrenddasVerhal-ten durcheinewohl definierteMethodenschnittstelle angegebenist. In Abbildung 3.10 isteineschematischeDarstellungeinesObjektesin einemobjekt-orientierten Entwurf gezeigt,wie sieim weiterenVerlaufdieserArbeit verwendetwird.

Abbildung3.10:SchematischeDarstellungeinesObjektesmit ZustandundVerhalten.

DurchdienachaußenfestgelegteFunktionalitat einesObjekteswird ein Systemunabhangigvon einer bestimmtenImplementierung.Solangeeine wohl definierte SchnittstellezurVerfugunggestelltwird, konnenandereObjekteubereineReferenzmit demObjektkommu-nizierenundAnfragenstellen,ohnedie genaueUmsetzungim InnerendesObjekteskennenzumussen.� Nachrichten: Um eineProgrammlogikumzusetzen,kooperierenverschiedeneObjektedurchAustauschvon Nachrichten.DieseKommunikationerfolgt mit demobenangesprochenensynchronen,auftrags-orientiertenMechanismus(RPC).Die NachrichtenrichtensichandieSchnittstelledesgerufeneObjektesund stellenAufrufe von SchnittstellenmethodendiesesObjektesdar, mit denender internerZustandabgefragtoder geandertwerdenkann.EineNachrichtbestehtallgemeinauseinemSelektor, der die Auswahl der angefragtenFunktio-nalitat angibt,undeinerReihevon Parametern,die alsEingabefur dieaufgerufeneMethodeverwendetwerden.DasausfuhrendeObjektbearbeitetdie Anfrageundsendeteineentspre-chendeNachrichtmit denAusgabeparameternzuruck.� Klassen: In einemObjektmodellwird eineKlassifizierungvon Objektenvorgenommen,dieObjektemit gleicherStrukturundgleichemVerhaltenzueinemTypbzw. einerKlassezusam-menfaßt.Wennein Objektdie gefordertenEigenschafteneinesbestimmtenTyps erfullt, soist dasObjekteineInstanzdiesesTyps.In objekt-orientiertenProgrammiersprachenwerdenKlassendefiniert,die StrukturundVerhaltenaller Objektein dieserKlassevorgeben.DurchErzeugungeinerInstanzderKlassewird einObjektmit eindeutigerIdentifizierungangelegt,


daseinenbestimmtenZustandunddasangegebeneVerhaltenaufweist.Die Instanzenin demSystemtauschendannNachrichtenaus,umeineProgrammlogikzu realisieren.

3.3.3 Verteilungsplattformen fur objekt-basierteSysteme

Zur EntwicklungundAusfuhrungverteilterSystemein heterogenenUmgebungensolltendie obengenanntenKonzepteundForderungenumgesetztwerden,um die inharenteKomplexitat handhab-bar zu machen.Eine Verteilungsplattformbzw. Middleware unterstutzt die Entwicklungund An-wendung,indemsieallgemeinausfuhrbareDienstefur verteilteSystemezur Verfugungstellt.DerBegriff Middlewarebeziehtsichdarauf,daßessichdabeium eineSoftwarehandelt,die zwischenBetriebssystemund der Anwendungarbeitet.In diesemAbschnitt sollen die Aufgabenund derAufbauvon Verteilungsplattformenfur objekt-orientierteSystemediskutiertwerden.Objekteeig-nensichdurchihreEigenschaftenbesondersgutalsGrundeinheitenderVerteilung.DerKommuni-kationsmechanismusmittelsMethodenaufrufekannauchuberRechnergrenzenhinweg ausgefuhrtwerden,indemdie ObjektreferenzenundSchnittstellenglobalbekanntgemachtwerden.Nachei-nerallgemeinerenEinfuhrungwird diestandardisierteMiddlewareCORBA [OMG98] alsBeispielherangezogen.

FolgendeAufgabeneinerVerteilungsplattformsollenhier hervorgehobenwerden(sieheauch[PR01]):� UnterstutzungdesObjektmodells: Die im ObjektmodellgefordertenKonzeptesollendurch

entsprechendeMechanismenderVerteilungsplattformunterstutzt werden.� OperationaleInteraktion: InteraktionzwischenzweiObjektensoll entsprechenddemMetho-denaufrufobjekt-orientierter Programmiersprachenmoglichsein.� EntfernteInteraktion: Auch die Interaktionzwischenzwei Adreßraumenbzw. uberSystem-grenzenhinweg soll unterstutzt werden.� Verteilungstransparenz: Es bestehtausProgrammsichtkein UnterschiedzwischenlokalerundentfernterInteraktion.� Technologieunabhangigkeit: UnterschiedlicheTechnologien,wieverschiedeneProgrammier-sprachen,Betriebssysteme,RechnerarchitekturenundNetzwerke, sollenunterstutzt undausProgrammsichttransparentgehaltenwerden.

DieseForderungenwerdenumgesetzt,indemmittelsderVerteilungsplattformeinehorizontaleSchichtzwischenAnwendungundBetriebssystemeingefuhrt wird. UnterhalbdieserSchichtwirddurchdie Middlewaredie Heterogenitat der Systemtechnologieabgedeckt.Oberhalbder SchichtliegendenAnwendungenwird derenFunktionalitatalsApplicationProgrammingInterface(API) inFormeinheitlicherDienstezurVerfugunggestellt.DasAPI hangtvonderProgrammiersprachederjeweiligen Anwendungund der Middleware-Implementierungab. Die VerteilungsplattformwirddemEntwickleralsProgrammbibliothekzurVerfugunggestellt.

Middleware am Beispielvon CORBA

CORBA stellt eineStandardisierungeinerVerteilungsplattformzur EntwicklungundAnwendungvon objekt-orientiertenverteiltenSystemendar. Der Standardwird von der ObjectManagement


Group(OMG) herausgegebenundweiterentwickelt. DerOMG gehoreneineVielzahlinternationa-ler Mitglieder (uber800im Jahr2001)ausdemBereichderInformationstechnologie an,dieanderStandardisierungeinereinheitlicheSpezifikationfur eineplattformunabhangigeund interoperableMiddlewaremitwirken.Die beidenwichtigstenStandardsderOMG sinddie ObjectManagementArchitecture (OMA), eineallgemeinePlattformzurBeschreibungverteilter, objekt-orientierter An-wendungen,unddie CommonObjectRequestBroker Architecture (CORBA), die eineSpezialisie-rungderOMA undeinekonkreteVerteilungsplattformbeschreibt.

Die ObjectManagementArchitecture beinhaltetein abstraktesObjektmodellund eineRefe-renzarchitektur. In Abbildung3.11ist derAufbauderReferenzarchitekturmit seinenKomponentengezeigt.Die Bezeichungenin denAbbildungendiesesAbschnittssindin Englisch,derSprachedesStandards,angegeben.

Abbildung3.11:OMA-Referenz-Architektur.

Die OMA Referenzarchitekturbeschreibtdie Beziehungenzwischenden Objekten,die imOMA Objektmodellabstraktdefiniertsind. Der Kern der Referenzarchitekturist der ObjectRe-questBroker (ORB),uberdendieObjektederverschiedeneKategorienkommunizieren.FolgendenKategoriensindin derOMA beschrieben:� Objekt Services: Hier werden horizontaleSystemdienstefestgelegt, die anwendungsun-

abhangigsindundhaufigbenotigt werden.Ein Beispielist derNamensdienst(NamingSer-vice), derdieZuordnungvonNamenundObjektreferenzenerlaubt.WeitereDienstesindz.B.Vermittlungs-undSicherheitsdienste.� Common Facilities: Die Common Facilities stellen horizontale AnwenderdienstezurVerfugung,die in verschiedenenAnwendungskontextenhaufigvorkommen(z.B. einDruck-dienst).


� DomainInterfaces: Hier werdenvertikaleDienstezwischenverschiedenenAnwendungsbe-reichenfestgelegt, wie etwa Medizin-,oderFinanzdienste.� ApplicationInterfaces: Die Application Interfacessind anwendungsabhangigeDienste,diedeshalbauchnicht vonderOMG standardisiertwerden.

Im CORBA-Standardwird dasabstrakteObjektmodellderOMA konkretisiert,indemBasisty-pen(boolean,long,float,...),zusammengesetztTypen(struct,union,...) undSignaturenzusammenmit einerAufrufsemantikfur dieoperationaleInteraktionfestgelegt werden.

DasGrundprinzipvon CORBA wird durchkommunizierendeObjektein einerClient/Server-Architektur verdeutlicht.Ein CORBA Client-Objekt ruft einen Dienst eines CORBA Server-Objektesmit Hilfe desunterliegendenORB auf. Dabeigilt dasobengenanntePrinzip der Ver-teilungstransparenz fur die Interaktionen.DerServer stellteineImplementationderObjektfunktio-nalitatdesentferntenObjektesbereit,aufdiemit Hilfe derObjektreferenzzugegriffenwerdenkann.Im CORBA-Standardwird dazuaufClient-SeiteeinStub-ObjektundaufServer-SeiteeinSkeleton-Objektmit Stellvertreterfunktioneingefuhrt.DerprinzipielleMechanismusbeieinemAufruf einesentferntenServer-ObjektesdurcheinClient-Objektmit CORBA ist in Abbildung3.12dargestellt.

Abbildung3.12:Aufruf vonMethodenverteilterObjektemit CORBA.

CORBA Komponenten

Die wichtigstenKomponentendesCORBA Standardswerdennun anhandder Abbildung 3.13vorgestellt.Alle zu CORBA gehorendenKomponentensind dort grau dargestellt. Die Server-und Client-Objektebzw. die StellvertreterobjekteStub und Skeleton gehoren zur jeweiligenAnwendung.Die gestrichelteLinie deutetden Weg einesAufrufs einer Methodeder Server-ImplementierungvomClient-Objektan.� ORB-Kern: Der ORB-Kern ist die zentraleKomponentevon CORBA undubertragt Metho-

denaufrufetransparentzwischenAdreßraum-bzw. Systemgrenzen.Er findet Objektimple-mentierungenim Netzwerkund vermittelt,sendetund empfangtDaten.Außerdemstellt erdemClientunddemServer dasORB-InterfacezurVerfugung.Im Zusammenhangderande-renKomponentennimmt derORB Operationenvom Aufrufadapter(Client-Seite)entgegenundliefert sieamObjektadapter(Server-Seite)wiederaus.


Abbildung3.13:CORBA Komponenten.

� IDL: Die InterfaceDefinitionLanguagedientderSpezifikationvonObjektschnittstellen.IDLermoglicht die Trennungvon Schnittstelleund Implementierungbzw. die UnabhangigkeitvonProgrammiersprachen,dasieeineeigenedeklarative Sprachedarstellt.DieseSpracheistanC++angelehntundbietetnebenderTypdefinitionauchdenMechanismusderSchnittstel-lenvererbungan.� IDL-Sprachanbindung: Durch Verwendung eines IDL-Compilers werden die IDL-Schnittstellenin die jeweiligeProgrammiersprachederAnwendungubersetzt.Die OMG de-finiertderzeitSprachanbindungenfur C,C++,Java,Smalltalk,Ada95undCOBOL.AuseinerSchnittstellendefinitionwerdenvom IDL-CompilerstetszweiStellvertreterobjekteStubundSkeletonerzeugt.Der StubdientdemClient alsProxy-Objektfur seineAufruf undverhaltsichwiedasentfernteCORBA-Objekt.DasSkeleton-ObjektbefindetsichaufdemServerundleitetdenAufruf andieMethodenimplementierungweiter. Die erzeugtenStub-undSkeleton-ObjektewerdennocheinmalvondemCompilerderverwendetenProgrammierspracheuber-setzt.� Aufrufadapter: Die Client-Objekteubergebenihre Aufrufe an denAufrufadapterentwederuberdasStub-Objektoderdirekt.Der ORB-Kernnimmt vom AufrufadapterdenjeweiligenAufruf entgegen. Es werdenzwei Aufrufadapterunterschieden.Das Static InvocationIn-terface(SII) dient zur Ubergabevon Aufrufen mit Hilfe desvom IDL-Compiler erzeugtenStub-Objektes.DasDynamicInvocationInterface(DII) wird demProgrammiererzur direk-tenVerwendungangeboten,umvon vorubersetztenStubsunabhangigzusein.� Objektadapter: Auf Server-Seitedient der Objektadapterals VerbindungzwischenORB-Kern und Objektimplementierung.Er verwaltet denLebenszyklusvon Objektenund sorgt


fur die AusfuhrungankommenderAufrufe. Eswerdenwiederzwei Arten von Objektadap-ternunterschieden.DasStaticSkeletonInterface(SSI)dientderAnbindungandenObjekta-daptermit Hilfe dervorgeneriertenSkeleton-Objekte.DasDynamicSkeletonInterface(DSI)erlaubtMethodenaufrufevon Objekten,derenSchnittstellenbei derEntwicklungnochnichtbekanntwaren.� InterfaceRepositoryundImplementationRepository: DasInterfaceRepositorystellteineDa-tenbankderTypinformationenbereit,mit demCORBA-ObjekteSchnittstelleninformationenzur Laufzeiterfragenkonnen.DasImplementationRepositorystellt analogeineDatenbankfur ObjektimplementierungenzurVerfugung.

Die ZusammenarbeitverschiedenerCORBA-Produktewird im Standarduberdie Inter-ORBProtokolle garantiert.Der CORBA-Standardgibt ein auf TCP basierendesProtokoll an,dasdortInternetInter-ORBProtocol (IIOP) genanntwird. Mit dieservertikalenSchnittstelleist die volleInteroprabilitat von CORBA gewahrleistet.Allerdings kannestrotzdemzu Kommunikationspro-blemenzwischenverschiedenenORB-Implementierungenkommen,da nicht alle Herstellersichumvolle Interoperabilitat bemuhen.WeitereDetailszurRealisierungvonAnwendungenmit COR-BA werdenin Kapitel7 beschrieben.Fur weitergehendekonzeptuelleInformationenzumCORBA-Standardwird auf [Sieg96] verwiesen.

3.4 Verarbeitung von Bildinf ormationen

In diesem Abschnitt werden Methoden zur Bildcodierung und Ubertragung in verteiltenVisualisierungsanwendungen diskutiert.DieseMethodenwerdenfur diehiervorgestellteSoftware-Architekturbenotigt, da mit Objekt-Reprasentationen gearbeitetwird, die im Spektrumzwischengeometrie-basiertenundbild-basiertenInformationenangesiedeltsind.

Zur UbertragungvonBilddatenin verteiltenNetzwerkumgebungenwerdenTechnikenbenotigt,dieeineReduzierungderInformationsmengeohnemerklichenVerlustanBildqualitatermoglichen.Die Verfahrenzur KompressiondigitalerBilddatenwerdenin zwei Gruppeneingeteilt,in verlust-freie (“lossless”)und verlustbehaftete(“lossy”) Methoden.Die Kompressionsratenliegenfur dieverlustfreienMethodenbei maximal2:1 und konnenheutefur verlustbehafteteCodierungbis zu100:1beiguterQualitat betragen,wobeidasVerhaltniszwischenOriginaldatenmengeundderDa-tenmengenachderKompressiongemeintist.

In Abbildung 3.14sindDatenratenvongebrauchlichenVideoformatenunddieUbertragungsra-tenheutigerNetztechnologiegegenubergestellt.Esist zu erkennen,daßschonfur dasCIF-Format(352x288Pixel) mit 30 Bildern pro Sekunde,8 Bit Farbtiefeund mit 4:2:2 Abtastung(d.h. dieFarbwerteU undV sindmit einervierfachgeringerenRateabgetastetalsdie Luminanz)eineDa-tenratevon 36 MBit/s erreichtwird. DieseDatenratekann in einemlokalen Netzwerknur mitFast-EthernetoderATM erzieltwerden,wahrendim Internetein garantierteBandbreitevon dieserGroßenordnungheutenicht zu erwartenist. Aus diesemGrundwurdenzur Ubertragungvon Bild-datenCodierverfahrenentwickelt, dieeinestarkeReduzierungderDatenmengeohnewahrnehmba-renQualitatsverlusterlauben.Verfahren,diedabeihauptsachlichgenutztwerdensinddieDiskrete-Cosinus-Transformation(DCT),dieQuantisierungvonDCT-Koeffizienten,diebewegungskompen-siertePradiktion,die Entropiecodierungund als neueresVerfahrendie Wavelet-Codierung.VieleCodierstandards,wie MPEG-1,MPEG-2,MPEG-4oderH.263,arbeitenmit mehrerenTechnikengleichzeitigund werdendeshalbals Hybrid-Codierverfahrenbezeichnet.Eine guteBeschreibungderheutegenutztenVerfahrenist in [ES98]zufinden.


Abbildung3.14:Gegenuberstellungvon DatenratenundNetzleistungfur digitaleVideoformate.

3.4.1 Bilddaten Codierung der erstenund zweitenGeneration

DasmethodischeVorgehenvon Codierverfahrenkannauf abstrahierteWeisedargestelltwerden,indemzweiaufeinanderfolgendeSchrittebenutztwerden.WenneinBild in grundlegendenEinhei-ten,sogenannteNachrichten(Messages[EK98]), eingeteiltwird, derenKombinationoderUberla-gerungdieganzeBildinformationwiedergibt, dannkanndasmethodischeVorgehenalsExtraktionund CodierungdieserGrundeinheitenbeschriebenwerden.In Abbildung3.15 ist dieseBeschrei-bungsweiseanschaulichdargestellt.

CodierstandardsdererstenundzweitenGenerationkonnennununterschiedenwerden,indemdie Grundeinheitbei der Verarbeitungnaherbetrachtetwird. Bei der Codierungmit MPEG-1istdieseGrundeinheitgegebendurchdie Pixel selbstzusammenmit ihrer Bewegungin der Bildse-quenz,die als numerischeWerteausdemBild extrahiertund dannweiterverarbeitetwerden.DieAlgorithmen,wie DCT oderBewegungsschatzung,arbeitenauf diesenEinheitenunddasBild isteineKombinationdieserEinheitenin FormeinesRechtecks.WeitereStandards,dieaufdieseWeisearbeitensindMPEG-2(ISO),H.261undH.263(ITU).

Bei Videocodierstandardsder zweitenGenerationsind nicht mehr Pixel die Grundeinheitenbei der Extraktionund Codierung,sonderneswerdennun zusammenhangendeObjekteeineBil-desalsgrundlegendeMessagesaufgefaßt.Auf diesezweidimensionalenBildobjektewerdendanndie weiterenCodiermethodenangewandt.Ein Objekt wird beschriebendurchseinenUmriß, sei-neTextur undseineBewegung.DurchKombinationbzw. Uberlagerungwird auf derDecodersei-te dasursprunglicheBild wiederrekonstruiert.DieseVorgehensweisehat nebender Moglichkeitzur hoherenKompressionderDaten(z.B. nur ein Bewegungsvektorpro Objekt)auchdenVorteil,daßsiemehrdermenschlichenWahrnehmungundInformationsverarbeitung im Gehirnentspricht


Abbildung3.15:Message-Extraktionund-CodierungbeidervisuellenDatenkompression.

unddamitein großeresPotentialfur zukunftigeAnwendungenbesitzt.Ein nochrelativ jungerin-ternationalerCodierstandard,der zur zweitenGenerationgehort, ist der ISO-StandardMPEG-4.MPEG-4([ISO99a]) wurdeentwickelt, um multimedialeund interaktive Inhalteauf Objektbasissynchronisiertzu ubertragen.Der Objektbegriff wurdeerweitert,indemnebenBildobjektenauchAudioobjekteund 3D Objektein codiertenSzenenenthaltenseinkonnen.Der Standardsprichtdahervon audio-visuellenObjekten.Die weiterenKomponentendesMPEG-4 Standardsnebender Audio/Videocodierungdienender optimalenUbertragungund Synchronisationdieseraudio-visuellenObjekte.Im RahmendieserArbeit wird jedochvor allem der VideocodierstandardvonMPEG-4benutztwerden.

SchemaeinesHybridcoders und -decodersder erstenGeneration

Die ArbeitsweiseeinesHybridcodecs(Coderund Decoder)soll anhanddesMPEG-1Videostan-dardserlautertwerden.In Abbildung 3.16 ist der Coderaufbauschematischdargestellt.Der Co-derbestehtausdenKomponentenfur die DCT-Transformation,Quantisierung(plus jeweils dereninverseTransformation),Bewegungsschatzung,BewegungskompensationunddemEntropiecoder.Hinzu kommenBildzwischenspeicherund Komponentenzur Subtraktionund Addition von Bild-informationen.Am EingangdesCoderswerdendie digitalenBilder sequentiellin Form von Pi-xelblockeneingelesen.Am Ausgangwerdendie entropiecodiertenInformationenuberdencodier-ten Bildinhalt, die Bewegungsvektorenund der jeweilige Codiermodus,also Inter oder Intra, alsBitstromzurUbertragungausgegeben.MPEGverwendetdreiFrametypen,namlichI-Frame(Intra-Modus),P-Frame(Inter-Modus)undB-Frame(Inter-Modus),die sichdarinunterscheiden,ob sieInformationausvorhergehendenbzw. nachfolgendenBilder zur Rekonstruktionbenotigen.EineBildsequenzist alsAbfolge dieserFrametypenmit eineranfanglichfestgelegtenOrdnungangege-ben.

Wird ein Bild im Intramoduscodiert,sowird seinInhalt zuerstDCT-transformiertundquanti-siert,unddasResultatdannuberdenEntropiecoderausgegeben.Gleichzeitigwird dasBild internwiederrucktransformiertund dannin einemBildspeicherabgelegt. DasdarauffolgendenBild seinun inter-codiert,d.h. zum Beispielein P-Frame.Fur diesesaktuelleBild wird nun eineBewe-gungsschatzungdurchgefuhrt, wobei daszwischengespeicherteI-Frameals Referenzbildbenutztwird. WenndieseSchatzungerfolgreichist, werdendie Bewegungsvektorenzusammenmit demresultierendenVorhersagefehleruberdenEntropiecoderausgegeben.Auf Decoderseitewird danndiesesaktuellenP-Framebestimmt,indemauf daszwischengespeicherteI-Framedie Bewegungs-


Abbildung3.16:SchemaeinesMPEG-1Videocoders.

vektorenund der Fehlerangewandtwerden.Im Falle von B-Frameswird dieseMethodeahnlichangewendet,nur daßhier zwei I- bzw. P-Framesals Referenzbilderbenutztwerden,wodurchdieBerechnungkomplexer, jedochdie Kompressionsrateerhoht wird. Fur alle Frame-Typengilt, daßdurchentsprechendeAnpassungderQuantisierungdieBitratedesAusgabestromsgeandertwerdenkannunddieBildqualitat sichaufdieseWeiseoptimierenlaßt.

Durch nahereBetrachtungder Komponentenin Abbildung 3.16 wird klar, daßder Decodervollstandig im Aufbau desCodersenthaltenist (siehemarkiertenBereich) [HH95]. Um wirk-lich nur denkomprimiertenCodierfehlerubertragenzu mussen,wird, wie obenbeschrieben,diebenotigte Information durch sofortigesDecodierungdes vorhergehendenBildes, anschließendeBewegungskompensationund durch Vergleich mit dem aktuellenBild im Coderberechnet.Dader arbeitsaufwendigsteTeil, namlich die Bewegungsschatzung,auf der Coderseiteerfolgt, wirddaszeitlichassymetrischeVerhaltendesMPEG-Codecsverstandlich.DerDecodererfullt lediglichdie wenigeraufwendigeAufgabe,nachder inversenEntropiecodierung,Quantisierungund DCT-Transformationdie benotigte Bildinformationim Zwischenspeicherzu halten.Anschließendwer-dendie BewegungsvektorenundderjeweiligenFehlerauf ein zwischengespeichertes Bild addiert,umdasdecodierteBild zuerhalten.

Ein objekt-basierter Videocodierstandardder zweitenGeneration: MPEG-4

Die Standardsder erstenGenerationsind block-basiert,d.h. die verwendetenAlgorithmenarbei-tenauf Blockenvon Pixeln desdigitalisiertenBildes.Ein Bild ist danneineKombinationvon Pi-xelblockenin FormeinesRechtecks.In VideocodierstandardsderzweitenGeneration,wie MPEG-4, werdenBilder nun als KombinationenausverschiedenenBild- oderSzenenobjektengesehen.JedesObjektbeziehtsichaufeineBildregionmit beliebigerzweidimensionalerFlacheundKontur


innerhalbdesrechteckigenGesamtbildes.DerMPEG-4-Videocodeccodiertfur jedesdieserObjek-te(VO) dieTextur-, Bewegungs-undKonturinformation.Die VideoobjekteeinerSzenenwerdeninelementareBitstromecodiert,mit einemMultiplexer zusammengelegt undalsmultiplexter MPEG-4-Gesamtstromubertragen.BeimDecodierenwerdedannKombinationendieserObjektemit Hilfeder Konturinformationdurch � -Blendingschrittweiseubereinandergelegt, um dasGesamtbildzuerhalten.

Abbildung3.17:StruktureinesMPEG-4Bitstroms.

Die StrukturdesGesamtbitstromsist objekt-basiertundin verschiedenenhierarchischeSchich-tengegliedert.In Abbildung3.17ist die MPEG-4-Bitstromstrukturfur eineVideoszenemit zweiObjektendargestellt.Die Schichtmit derhochstenOrdnungist dieVideoSession(VS), diealleOb-jekteundderenZuordnungin derSzenenbeschreibt.Darunterfolgt dieObjektschichtVideoObject(VO) mit deneigentlichenObjekten.Als nachstesfolgt die SchichtVideoObjectLayer(VOL), dieein Objekt in verschiedenenAuflosungenbeschreibt.Die untersteEbenebildet die Video ObjectPlane(VOP)-Schicht,die die eigentlichecodierteBildinformationfur ein Objektenthalt. Bei derUbertragungeinerMPEG-4Szenewird zuerstdieSzeneninformationubermitteltunddannwerdendiecodiertenInhaltealsgemultiplexte Elementarstromegesendet.

NebenVideoobjektenkonnenMPEG-4SzenenauchAudioobjekteund3D Objekteenthalten.Die VerbindungzwischendiesenObjektenundderbinarenSzenenbeschreibung(BIFS)wird durchdieObjektdeskriptoren(OD)gewahrleistet.In Abbildung3.18sindderAufbaueinesMPEG-4Stro-mesunddieVorgangebeiderDecodierungveranschaulicht.NachdemDemultiplexenwird dieSze-nenbeschreibung zusammenmit denObjektdeskriptorendazuverwendet,die decodiertenObjektein einerSzeneanzuordnen.Daraufwerdendie 3D Objektegerendertund dieseBildinformationzusammenmit denVideoobjektenalsGesamtszeneangezeigt.


Abbildung3.18:DecodierungeinesMPEG-4-Bitstroms:RekompositionundRendering.

3.4.2 Netzwerkubertragung von codiertenBilddaten

Die Ubertragungvon digitalen Bilddaten in codierterForm geschiehtin der hier untersuchtenSoftware-Architekturin einereigeneSchicht.Die Bilddatenwerdennicht alsAufruf- oderRuck-gabeparametereinesentferntenMethodenaufrufsuber eine Middleware ubertragen,sondernalsBitstrommit Hilfe derProtokolle TCPbzw. UDPuberSocketsgesendetbzw. empfangen.

TCPist ein verbindungs-orientiertesgesichertesTransportprotokoll, mit demim Voll-Duplex-Betrieb und bei gesicherter, unveranderterReihenfolgeStrome von Bytes ausgetauschtwerdenkonnen.Die Adressierungerfolgt uber IP-Adressen(IP: InternetProtocol) und eineAnzahl vonlogischenPorts.Die Verzogerungszeit,die dadurchentsteht,daßverlorenePaketemit TCP nocheinmalgesendetwerden,machtdiesesProtokoll fur die Bilddatenubertragungmit Echtzeitanfor-derungenungeeignet.Fur Einzelbilddaten,die garantiertfehlerfrei beim Empfangerankommensollen,ist TCPjedochdemUDPProtokoll vorzuziehen.

Zur schnellenUbertragungvon Bildsequenzenwird ein verbindungsloserungesicherterTrans-portmechanismusbenotigt, bei demallerdingsauchDatenverlorengehenkonnen.Mit demUserDatagramProtocol (UDP) wird ein solchesProtokoll angeboten.UDP setztauf demIP-Protokollauf und unterstutzt dasMultiplexing von Datagrammenzur UbertragungzwischenRechnernimInternet.NebenderErstellungundKontrollevon ChecksummenbietetUDP keineweiterenDien-ste.Vor allem Multimedia-Anwendungenmit Echtzeitanforderungen nutzendasUDP-Protokoll,um beimBenutzereinenkontinuierlichenvisuellenEindruckerzielenzu konnen.Die PaketierungundBehandlungvon FehlernbeiderUbertragungmußdabeianhohereSchichtenderAnwendungweitergegebenwerden.Als weiteresProtokoll, dashohereFunktionalitatenwie z.B.Streamingun-terstutzt,seihierdasReal-TimeTransportProtocol(RTP)genannt.EineweiterfuhrendeDiskussionzuMultimedia-Datenubertragung wird z.B.vonSteinmetz[Stei00] gegeben.

In Abbildung3.19ist ein Szenariozur Ubertragungvon codiertenBilddatenmittelsTCPbzw.UDP im Internetgezeigt.Die digitalen Bildaten werdenmit einemBildcoder komprimiert unddannandenBild-Server ubergeben.Der Bild-Server enthalt eineninternenDaten-Buffer, um Da-


Abbildung3.19:NetzwerkubertragungvoncodiertenBilddaten.

tenverlustezu vermeiden.Uber eineSocket-Verbindungzum Benutzerrechnerwird der codierteBitstromim Netzverschicktund auf Client-Seitevon einemBild-Client eingelesen.BeideSeitenverwendendie Socket-Implementierungihrer jeweiligenProgrammiersprache.Am Client werdendie BilddatenubereinenDaten-Buffer an denBild-Decoderweitergegeben,der als AusgabediezurucktransformiertenBilddatenaneinenDisplayweiterleitet.Bei derDecodierungentstehenge-wisseInformationsverluste,wennkein Lossless-Verfahrenangewendetwurde.Fur Bildsequenzenfindenin derRegelsolcheLossy-CodierverfahrenAnwendung,dieversuchen,dieInformationsver-lusteim nichtwahrnehmbarenBereichzuhaltenundeinehoheKompressionsratezuermoglichen.

ZurVersorgungmehrererBenutzermit gleichenBilddatenwerdenMechanismenverwendet,dieentwederamServer eineVervielfaltigungderDatenstromein mehreregleicheStromevornehmenodereswerdenMulticast-Methodenbenutzt.In diesemFall werdendie Bildatenan alle Teilneh-mer einerMulticast-Gruppeversendet,ohnedaßeineDatenvervielfachungnotig wird. Multicast-Gruppenmussenin diesemFall allerdingsvon derunterliegendenInfrastrukturunterstutzt werden(siehe[MB94]).

Kapitel 4

Konzeptezur verteilten 3DVisualisierung

In diesemKapitel soll ein Uberblick uberdenStandder Forschungauf demGebietder 3D Vi-sualisierungskonzepte gegebenwerden,die zum verteiltenArbeitenmit 3D Dokumenteneinge-setztwerden.Einfuhrendwerdendie Komponenteneinesinteraktiven 3D Visualisierungssystemsin verteiltenUmgebungenbeschrieben.In diesemZusammenhangwerdenauchwichtigeTechni-kenzurVerteilungundzurSynchronisationvonSzenengraphendiskutiert.DanachwerdenKonzep-te zur VerteilungeinerVisualisierungs-Pipeline vorgestellt,d.h.Visualisierungskonzepte fur eineneinzelnenBenutzerin einemverteiltenSystem.Darunterfallen vor allem lokalesund Remote-Renderingin einerClient/Server-Umgebung.AnschließendwerdenMehrbenutzersystememit meh-rerenVisualisierungs-Pipelinesdiskutiert,die interaktive 3D Visualisierungzur UnterstutzungderKooperationvonBenutzerneinsetzen.ZumAbschlußdesKapitelswerdenVerfahrenbehandelt,dielokaleundRemote-Visualisierungvon3D Dokumentenkombinieren.

4.1 Eine Klassifizierung verteilter 3D Visualisierungsysteme

EinegeeigneteKlassifizierungfur verteilteVisualisierungssystemewird zumBeispielvon Brodlieetal. [BDG98]angegeben.Tabelle4.1gibt dieverwendeteKlassifizierungwieder:Unterkooperati-verVisualisierungwird hierdiesynchronisierte3D VisualisierungdurchmehrereBenutzerverstan-den,wobeidiebearbeiteten3D DokumenteganzoderzumTeil ubereinstimmen.Im folgendenwer-denSystemebesprochen,die immeraufmehrereRechnerverteilt sindunddievoneinem(verteilteVisualisierung)bzw. mehrerenBenutzern(verteiltekooperative Visualisierung)verwendetwerden.Die Verteiltheitkannsichdaherauf die Daten,auf die ProzessederVisualisierungs-Pipeline oderaufdieBenutzerbeziehen.

4.2 Komponentenverteilter 3D Visualisierungsysteme

Wie in Abschnitt3.2 besprochenwurde,konneninteraktive 3D VisualisierungssystemedurcheinModell bestehendauseinerRendering-Pipelineund einerAktions-Pipelinebeschriebenwerden.Hinzu kommenin realenSystemennochKomponentenzumEinlesenbzw. Verteilenvon Geome-triedaten,zurUbertragungbzw. DarstellungvonBilddatenundzurUbertragungvonanderenDaten,wie BenutzeraktionenoderSicherheitsinformationen.

56

KAPITEL 4. KONZEPTEZUR VERTEILTEN 3D VISUALISIERUNG 57

Anzahl Rechner 1 M————-

Anzahl Benutzer1 Zentrale Verteilte

Visualisierung VisualisierungN Kooperative Verteilte

Visualisierung KooperativeVisualisierung

Tabelle4.1:KlassifizierungvonverteiltenVisualisierungssystemen.

In diesemAnschnittwird esdarumgehen,die KomponenteneinesVisualisierungssystemsaufeineverteiltesSystemabzubilden.Dafur werdendiewichtigstenBestandteilein abstrakterFormalssymbolischeKomponentendargestellt.Fur dieweitereDarstellungwerdendieseSymboleverwen-det,umdenAufbauverschiedenekonzeptionellerSystemansatzezubeschreiben.In Abbildung4.1ist ein Visualisierungssystemmit lokalemRenderingunterVerwendungeinerRendering-PipelineaufdemClient-RechneraufdieseWeisegezeigt.Die wichtigstenKomponentenfur eineallgemeineBeschreibungvon3D Visualisierungssystemensind:� die3D Dokumenteselbst,� die3D Rendering-Pipeline,� eine2D Abbildungskomponente,� eineKomponentezur Interaktionmit den3D Daten,� eineSynchronisationskomponente fur verteilteSzenengraphen,� eineSystemgrenzezwischenRechnern.

Fur all dieseKomponentensind Symbolein Abbildung 4.1 festgelegt, mit denenVisualisie-rungssystememodelliert werdenkonnen.Die interneFunktionalitat der Komponentenist dabeigekapselt.Fur die KomponentenInteraktionund Synchronisationvon verteiltenSzenengraphenwerdendie verwendetenTechniken in denAbschnitten4.2.2und4.2.3diskutiert.Außerdemwirdin Abschnitt4.2.1die dynamischeVerteilungvon Szenengraphenbesprochen.Einzelheitenzu derinternenUmsetzungderanderenKomponentenwurdenin Abschnitt2.2(Digitale Dokumente) undKapitel3 (Methoden) beschrieben.

Die verteilteUmgebung wird hier durchein Client/Server-Systemreprasentiert,in demmin-destensein Server-Rechnerund ein Benutzerrechnerexistieren,die durchein Netzwerkverbun-densind. Die Bereichevon Server- und Client-Rechnersind schraffiert dargestellt.Es wird vor-ausgesetzt,daß sich die 3D Dokumente,also die Geometriedaten,anfanglich auf dem Serverbefinden.Außerdemgibt es Moglichkeiten zum Retrieval und zum Zugriff auf die Dokumente,die es demBenutzererlauben,mit den Dokumentenzu arbeiten.Die Systemgrenzegibt in denDarstellungenjeweils denBereichzwischenbeidenRechnernmit denRechnergrenzenund demverbindendenNetzwerkan. Im wesentlichenfindet in diesemBereicheineUbertragungvon Do-kumentdaten(Geometrie-,Bild-, Sicherheitsdaten)und von Synchronisationsdaten (Middleware-Kommunikation)mit Hilfe geeigneterNetzwerkprotokolle statt.In denweiterenDarstellungenmit


Abbildung 4.1: SymbolischeBeschreibung von KomponenteneinesverteiltenVisualisierungssy-stemsmit lokalem3D Renderingfur einenBenutzer.

den angegebenenSymbolenwerdendie Bereichevon Server- und Client-Rechnerzur Vereinfa-chungnichtmehrexplizit dargestellt,sonderndurcheineSystemgrenzerepasentiert.

Die 3D Visualisierungwird als eine Abbildung der 3D Informationenauf visuelle 2D In-formationenbeschrieben.Dies wird mit densymbolischenKomponentendargestellt,indemeineRendering-Pipelinemit der 3D Szeneals Input verbundenwird und derBilddaten-OutputmittelsRasterung,UbertragungundDarstellungamAusgabegerat visualisiertwird (sieheAbbildung4.1).Die 2D Abbildungwird aufdieseWeisevondenvorhergehendenProzessenderRendering-Pipelinegetrennt,um spater bei den Verfahren,die lokale und Remote-Visualisierungkombinieren,einekonsistenteDarstellungsweisezuerlauben.

4.2.1 Verteilung von 3D Szenen

Dasichdie3D Dokumenteim FalleeinesmoglichenDigital-Library-SzenariosanfanglichaufdemServerbefinden,benotigt eineSoftware-ArchitekturzumverteiltenArbeitenMoglichkeitenzurVer-teilungvon3DDokumenten.In diesemAbschnittsollenMethodenzurUmsetzungdernotwendigenFunktionalitat erlautertwerden.

Auf Server-Seitewerdendie 3D Dokumenteentwederin einerexternenDatenbankvorliegenoderbereitsim SzenengrapheinerRemote-Visualisierungs-Anwendung integriert sein.In beidenFallensoll derBenutzerdurcheineeinfacheAuswahlaktion,dieerzumServerschickt,in dieLageversetztwerden,ein 3D DokumentoderTeile davon in seinelokaleVisualisierungsanwendung zu


integrieren.Dazumuß jedocham Server zuerstauf die ausgewahltenDatenzugegriffen werdenundeineUbertragungin einembekanntenDatenformatubereineSystemgrenzehinweg stattfinden.Die einzelnenSchrittewerdennun im Detail beschrieben.In Klammernhinter jedemPunkt istangegeben,obderClientoderderServer dieAktion ausfuhren.� Selektion (Client): Je nachdemob sich das gewunschte 3D Dokument in einer ex-

ternen Server-Datenbank oder als Szenengraphin einer synchronisiertenRemote-Visualisierungsanwendung befindet, wird der Benutzer entweder uber eine WWW-Schnittstelleauf die externenDB (Fall A) oderubereineSelektionsmethodeseinerlokalenVisualisierungsanwendung undeineSchnittstelleauf denRemote-Szenengraphenzugreifen(Fall B). Im Fall A werdenentsprechendeRetrieval-Daten(Metadatenoderinhalts-basierteMerkmale)an denServer geschicktund dort ausgewertet.Im Fall B wird in der Regel diePositionaufdemBildschirmbeimAuslosenderSelektionaktionzumServer ubertragen.� Retrieval (Server): Die zum Server gesendetenDatenwerdennun dort zum Retrieval ver-wendet.Im Fall A werdenmit Hilfe einesSQL-Select-Befehles,mit dem die Retrieval-Datenan das DBMS weitergegebenwerden,die passendenDokumentdatenaus der Da-tenbank ausgelesen.Im Fall B wird mit Hilfe der Positionsdatenvon der Remote-Visualisierungsanwendung einePick-Aktion (siehehierzu[Wer98]) auf ihremSzenengraphausgefuhrt.Dabeiwird davonausgegangen,daßdieVisualisierungamServermit deramCli-entsynchronisiertist, d.h.dasderBlickpunktund-winkel zu jederZeit ubereinstimmen.DasResultatder Pick-Aktion ist ein Szenengraphpfad, der nun in eineninternenPuffer oderineineserver-seitigeDateigeschriebenwird. Die Ausgabeerfolgt dabeiin einemFormat,daszur UbertragunggeeignetundaufbeidenSeitenbekanntist.� Ubertragung (Server oder Client): Hier kann zwischeneinem Push-Verhalten,bei demder Server selbststandig die am Client benotigten Datendort bereitstellt,und einemPull-Verhaltenunterschiedenwerden,bei demder Client die Informationenvom Server herun-terladt. Im Fall A handeltessichum ein Pull-Verhalten,dadasHTTP-Protokoll mit einemGet-Befehlvon Client-Seitearbeitet.Die Ubertragungwird auchvon diesemProtokoll kon-trolliert. WenndieUbertragungzwischenzweiobjekt-orientiertenVisualisierungsanwendun-genablaufensoll, wie im Fall B, ist sowohl einePull-Verhaltenalsauchein Push-Verhaltenrealisierbar. Die ausgewahltenundin eineminternenBuffer bereitliegendenDatenwerdeninFormvonByte-Feldernubertragen.WenneinPull-Verhaltenimplementiertist,wird vomCli-ent mittels einerMiddleware-SchnittstelleeineGet-Methodeam Server aufgerufen,die alsRuckgabeparameterdasentsprechendeByte-Feldubergibt. Bei einemPush-Verhaltenwirdumgekehrt vom Server die Set-MethodeeinesentferntenObjektsamClient aufgerufen,dasin diesemFall einMiddleware-Server-Objektdarstellt.Die Set-Methodeenthalt dannalsEin-gabeparameterdieausgewahltenDatenalsByte-Feld.� Lokale Integration (Client): Am Client mussendie Datennun von der Visualisierungsan-wendungeingelesenwerden.Durch denAufruf einerentsprechendenMethodewerdensiedaraufhinin Form einesneuenSzenengraphenin die Anwendungintegriert oderals Sub-Szenengraphin einebestehendeSzeneeingefugt.

4.2.2 Interaktion mit verteilten Szenengraphen

Die 3D Interaktionmit Hilfe einesobjekt-orientiertenVisualisierungs-APIgeschiehtuberBenut-zerschnittstellenereignisse, im weiterenUser InterfaceEventsgenannt,und die Ubertragungder


Benutzeraktionenauf die interneSzenendatenbank,alsodenSzenengraph.JederKnotendesSze-nengraphenenthalt Zustandsdaten(FieldValuesabgelegt in Fields) undstelltMethodenzumZugriffauf die Datenbereit.Um mit einer3D Szenezu interagieren,d.h.wahrendder laufendenVisuali-sierungManipulationenanderSzenevorzunehmen,kannderBenutzerdieseMethodenschnittstellenutzenunddieentsprechendenFeldereinesObjektesandern.Als BeispielseieineinfachesKugel-objektgenannt,dasin einemZustandsfeldseinenRadiuswertenthalt. DurchAufruf einerMethode�¢s�04�£2%:�¤¦¥o�§��¨%2§©�¥osx$ desKugelobjektesbzw. �¢s�0�&N2§©�¥os��¨§2%©�¥*sx$ bei direktemZugriff auf dasFeldkannderBenutzerdenRadiusinteraktiv andernunddasResultatin derVisualisierungsofortsehen.

UmnunaufentfernteSzenengraphenin einerverteiltenUmgebunginteraktiv (RemoteInteracti-on, siehehierzuauch[ESE99]) zugreifenzukonnen,mussendiebenotigtenMethodendesObjektesubereineMiddleware-Schnittstellezuganglichgemachtwerden.Dazuwerdendie auf Client-SeiteerzeugtenEventszur Server-Anwendungubertragenundlosendort die entsprechendeAktion aus.Dieswird mittelseinesCallback-Mechanismus,derbei einerSelektionausgelost wird, undeinesMiddleware-Methodenaufrufes vom Client zum Visualisierungs-Server realisiert.Im Fall der in-teraktivenManipulationvon 3D ObjektenwerdendurcheineAktion die FeldwertedesentferntenObjektesgeandert,die seinegeometrischenEigenschaftenfestlegen.Die Visualisierungwird dannautomatischvonderAnwendungaktualisiertundeswird z.B.im Fall einerRemoteVisualisierunsg-ArchitektureinvisuellesFeedback mittelsderBilddatenzumClientgeliefert.

Abbildung4.2:Interaktionmit einementferntenSzenengraphenin einemverteiltenSystem.

Mit dem folgendenVerfahrenkanndie Umsetzungder Remote-Interaktionvereinfacht wer-den.Der Zugriff auf die FelderentfernterObjektesetztnaturlich voraus,daßdie AnzahlundArtder ZustandsfeldereinesObjektesbeim Zugriff erkanntwerden.Ein Objekt musstealso bei je-demZugriff identifiziertundeinerKategoriezugeordnetwerden.Dieskannmanumgehen,indemmanzum Zeitpunktder Selektionein Transformer-Objekt in die GruppedesselektiertenObjek-tesan ersterStelleeinfugt. DiesesTransformer-Objekt hat einefestgelegte Schnittstelle,mit derubereinenentferntenMethodenaufrufsehrvielegeometrischeTransformationenmit einemObjektdurchgefuhrt werdenkonnen.Mit OpenInventor ist auf dieseWeisez.B. die Skalierung,Rotati-on und Translationvon beliebigen3D Objektenmoglich, die sich in der gleichenGruppehinterdemTransformer-Knotenbefinden.Nachdemdie Interaktionmit demspeziellenObjekt beendet


ist, wird dasTransformer-ObjektwiederausderGruppeentfernt.In Abbildung4.2 ist derZugriffauf einenentferntenSzenengraphenmit Hilfe einesTransformer-Knotensgezeigt.Indemmit ei-nemMiddleware-Methodenaufruf (RPC,sieheKapitel 3) auf die FelderdesTransformer-Knotenszugegriffen wird, kannz.B. der Radiusdesin der gleichenGruppeliegenden3D ObjektesdurchSkalierungverandertwerden.Um einallgemeineinsetzbaresVerfahrenfur denZugriff aufentfern-te Dokumentobjektezu ermoglichen,mussendie SchnittstellendynamischerzeugtwerdenundimSystembekanntgemachtwerden.BeliebigeParametereinesentfernten3D Objekteswerdensofurdie Interaktionzuganglichgemacht.In Abschnitt9.3.2vonKapitel9 wird einsolchesdynamischesVerfahrenbeschrieben,mit demeinemBenutzerauchdie Synatxund SemantikeinerentferntenMethodezur Parametermanipulationim Moment desZugriffs auf ein Objekt verfugbargamchtwird.

4.2.3 Synchronisationvon verteilten Szenengraphen

Fur kooperative Anwendungen,die mit 3D Visualisierungarbeiten,ist esnotwendig,die SzenenmehrererClientszu synchronisieren.DabeiwerdenlokaleAktioneneinesBenutzersuberSystem-grenzenhinweg zu denanderenBenutzeranwendungenubertragenunddort in dergleichenWeiseauf den Szenengraphangewendet.Zur vollstandigenSynchronsiationvon verteiltenSzenengra-phenwerdensowohl die KamerabewegungeneinesBenutzers,alsauchseineObjektinteraktionenmit Hilfe von Middleware-Methodenaufrufen aufdenentferntenSzenengraphubertragen.Teilwei-seSynchronisation,bei derdie Navigation jedesBenutzersunabhangig ist und lediglich alle Ob-jektinteraktionenim ganzenSystemsynchronisiertseiensollen,wird durchdie UbertragungvonSelektions-Eventsunddie AktualisierungderentsprechendenFeldwertein denausgewahltenOb-jekten realisiert.Die Synchronisationverlauft dabeinaturlich in beideRichtungen,so daßjederBenutzerdieAktionenalleranderenBenutzersehenkann.

In Abbildung 4.3 ist die vollstandige Synchronisationzweier verteilter Visualisierungs-anwendungengezeigt,bei der ein aktiver Client seineAktionen auf einenim MomentpassivenClient ubertragt.Die Kamerasynchronisationgeschiehtuberein Sensorobjektim aktiven Szenen-graph,dasbei jederAnderungdesKameraobjekteseinenEventauslost.UbereinenCallback wirdfur diesesEreigniseineMethodeaufgerufen,die nunihrerseitsubereineMiddleware-SchnittstelledieentsprechendenParameterderentferntenKameraaktualisiert.Im wesentlichenmussenzurKa-merasynchronisationdiePosition,derBlickwinkel unddieBlickrichtungbekanntgemachtwerden.

Zur SynchronisationvonObjektinteraktionenwerdenubereinenCallback dieEvent-Parameter,diebeiderSelektioneinesObjektesamaktivenClientermitteltwurden,zurentferntenAnwendungubermittelt.Dort wird mit diesenParameterndie gleicheAktion wie amlokalenSzenengraphaus-gelost.In diesemFall ist dieseinenPick-Aktion,diediePfadinformationdesbetreffendenObjektesim Szenengraphzuruckgibt. Mit Hilfe dieserPfadinformationwerdendanndie entsprechendenFelderdesausgewahltenObjektesaktualisiert.In [HSF99] wird ein Namensschemafur verteilteSzenengraphenvorgeschlagen,dasdie Identifikationvon beliebigenObjektenin verteilten,aberubereinstimmendenSzenengraphenermoglicht. Ein solchesSchemazur Identifikation ist notig,wenneineteilweiseSynchronisationvorliegt, d.h.wenndie Benutzerunabhangigvoneinanderna-vigierenkonnenunddaherdieBildschirmpositionenbeiderSelektionnichtmehrubereinstimmen.FallseinevollstandigeSynchronisationrealisiertist, kanndieIdentifikationeinfacheruberdieBild-schirmpositiondesselektiertenObjekteserreichtwerden.


Abbildung 4.3: VollstandigeSynchronisationzweierverteilter Szenengraphenuber Middleware.Aktiver Client (rechts)undsynchronisierterClient (links).

4.3 Konzeptezur Verteilung einer Visualisierungs-Pipeline

Wie in Kapitel2 im Abschnitt2.5beschrieben,sinddiewichtigstenKriterien,diezurUnterstutzungverteiltenArbeitensin 3D Visualisierungsumgebungen erfullt werdensollten,derSchutzvon Do-kumenten,dieBerucksichtigungderverfugbarenUbertragungsbandbreite zueinemClient-Rechnerunddie BerucksichtigungseinerlokalenLeistung.Bei der interaktivenVisualisierungwird zudemeineminimaleVerzogerungszeitfur dasvisuelleFeedbackbenotigt, um einenkontinuierlichenvi-suellenEindruckbeimBetrachterzuerreichen.

Im folgendenwerdenverschiedeneKonzeptezur verteilten3D Visualisierungvorgestelltundmit BeispielenausderLiteratur illustriert. Anhandder angegebenenKriterien werdendie Vortei-le und Nachteileder einzelnenKonzeptefur denEinsatzin verteiltenVisualisierungsanwendun-gendiskutiert.Im Mittelpunktstehendabeioffene,kooperative Informationsraume,d.h.Umgebun-genvernetzterRechnermit einemClient/Server-Ansatz,dievonaußenubereineAuthentifizierungzuganglichsindunddieKooperationzwischenBenutzererlauben.Offenbzw. vonaußenzuganglichmeinthier, daßdie NutzungderangebotenenDienstenicht auf einenvorhereingeschranktenunddaherabgeschlossenenBereich,wie z.B. ein Intranet,beschrankt ist. DadurchwerdenSicherheits-aspekteunddieBerucksichtigungvon Heterogenitat desInformationsraumesbesonderswichtig.

Der ProzeßderVisualisierungverlauft vom Einlesender3D Dokumente,uberdas3D Rende-ring bis zur Darstellungder visuellenDatenz.B. auf einemBildschirm odermit Hilfe einesim-mersivenDisplays.Die gebrauchlichstenKonzepte,die sichin derVerteilungderVisualisierungs-komponentenunterscheiden,sind die lokale 3D Visualisierungund die Remote-VisualisierunginverteiltenSystemen,die im folgendenbeschriebenwerden.Dabeibefindensichdie3D Dokumenteanfangsauf demServer und die Benutzergreifenvon ihrem RechneruberdasNetzwerkauf dieentferntenDatenzu.


4.3.1 Lokale 3D Visualisierungmit Datenreplikation

DaswichtigsteMerkmaldiesesKonzeptesist die UbertragungeinerKopieder3D DokumenteaufdenClient-Rechner, d.h. eineReplizierungder Daten.Die Visualisierungs-Pipelinewird danachvollstandigauf demlokalenRechnerausgefuhrt und alsonicht verteilt. Prinzipiell mußnachderDatenverteilungkeineVerbindungzum Server gehaltenwerden,da auchdie Interaktionmit den3D Datenkomplettlokal ausgefuhrt wird. Wie spatererlautertwerdenwird, verlangenkooperativeAnwendungen,die nachdiesemAnsatzarbeiten,jedocheineSynchronisationdurchUbertragungvonAktionenzudenanderenClient-Anwendungen.

In Abbildung4.1vom AnfangdiesesKapitelsist eineClient/Server-Umgebungzur lokalen3DVisualisierungmit Datenreplikationgezeigt.Nachdemdie3D Datenin denClient-Bereichubertra-genwurden,findetdortdasEinlesenin die3D Rendering-Pipeline,das3D RenderingselbstunddieAusgabeaufdenBildschirmstatt.Die Interaktionwird durchdieAnwendungvonAktionenaufdie3D Datenrealisiert,indemz.B. die Feldwertein denZustandsfelderneinesbeliebigenObjektkno-tenseinesSzenengraphenverandertwerden(wie in Abschnitt4.2.2beschrieben).DieKomponentenderinteraktivenVisualisierungsindin Abbildung4.1durchdiehiergewahltenSymboledargestellt.

Die VorteilediesesVorgehenssindzumeinendiemaximaleVerfugbarkeit der3D Datenfur denBenutzerundzumanderendieminimaleVerzogerungbeiderVisualisierung.Beidesist gewahrlei-stet,dadieDatenlokal alsKopievorliegen.EineweitereVerminderungderVerzogerungszeitkannin derRegel auchnicht durchAusnutzungeinerleistungsstarken Server-MaschinezumRenderingerzieltwerden,wie esbei derRemote-Visualisierunggeschieht,dadie UbertragungderBilddatendurcheinNetzwerkimmereinerelativ großeVerzogerungbedeutet.

DerAnsatzlokaler3D Visualisierungmit DatenreplikationbringtaberauchNachteilemit sich.Zum einenwird fur sehrkomplexe Modelledie UbertragungderGeometriedatenselbstzumPro-blem,daeineentsprechendhohegarantierteBandbreitez.B. im Internetnicht zurVerfugungsteht.Wenn ein Benutzerin einer großen,zusammenhangenden3D Welt navigiert, kann die Geome-trieubertragungein flussigesArbeitenunmoglich machen.Zum anderenkanndie lokaleLeistungundKapazitatdesClient-Rechnersfur sehrkomplexeModellenichtausreichendsein.DieserPunktist allerdingsdurch die heutigerasanteEntwicklungder Prozessorenleistungund Speicherkapa-zitatennicht in einemahnlichenMaßekritisch,wie dervorhergehendePunkt.Schließlichwird dieReplizierungvon geschutzten3D Dokumentenin offenenUmgebungenzu einementscheidendenProblem.Wennzur 3D Visualisierungimmer Kopiender Originaldatenverteilt werdenmussen,dannkonnenz.B. Urheberrechtenicht mehrohneweiteresgeschutzt undVertraulichkeitsanforde-rungennichterfullt werden.

Ansatzeund Software-Architekturen in der Literatur

In der Literatur sind einigeSystemebeschrieben,die nachdiesemKonzeptder Datenreplikationarbeiten.In [HSF99] beschreibenHesinaet al. eineSoftware-Architekturbei der 3D SzenenalsKopieneineszentralenSzenengraphenauf demServer verteilt werdenundUpdatesuberdenSer-ver an andereClient-Rechnerin einerkooperativen Anwendunggesendetwerden.Dort wird dasVisualisierungs-Toolkit OpenInventorzur Realisierungverwendetundentsprechendzur Synchro-nisationvon verteiltenSzenengraphenerweitert.Schmalstieg undGervautzbeschreibenin [SG96]ein System,bei dem Geometriedatenadaptiv ubertragenwerden,d.h. daßnur die jeweils zumRenderingbenotigte 3D Informationam Client vorgehaltenwird. In [HS98] beschreibenHesinaundSchmalstieg eineSoftware-Architektur, diedieseangepaßteGeometrieubertragungin Internet-basiertenvirtuellen Umgebungenumsetzt.Dieserlokale Ansatzwird dort als RemoteRendering


bezeichnet,wasjedochnicht mit derweiterunterdiskutiertenRemote-Visualisierungverwechseltwerdendarf.

In Einzelbenutzeranwendungen wird der lokale Visualisierungsansatzsehroft verwendet,in-demdie DateneinfachubereinenWWW-Server zumHerunterladenbereitgestelltwerdenunddieVisualisierungganzdemClient uberlassenwird. DieseTechnikwird im offenenInformationsraumdesWWW benutztunddurchdieAngabevon MIME-Types(siehe[RFC1521]) unterstutzt,diemitdenDatenubertragenwerdenundangeben,welcheAnwendungzurDarstellungaufgerufenwerdensoll. Einesder erstenSystemedieserArt wurdevon Ang et al. [AMD94] vorgestellt(sieheauch[RMW98]).

4.3.2 Remote3D Visualisierungmit zentraler Datenhaltung

Bei diesemKonzeptwird die Visualisierungs-Pipelinesoverteilt, daßdasEinlesenderDaten,das3D Renderingunddie Ausgabevon digitalenBilddatenamServer geschieht.Die generiertenBil-derdes3D Dokumenteswerdendannin komprimierterForm zumClient-Rechnerubertragenunddortdargestellt.In Abbildung4.4ist diesgezeigt,indemeineTrennungder3D Rendering-PipelineamServerundder2D Abbildungim Client-BereichubereineSystemgrenzehinweg vorgenommenwurde.Die Interaktionmit den 3D Datengeschiehtvom Client-Rechneraus,indem die Aktio-nenwiederuberdie Systemgrenzehinweg zum Server ubertragenund dort angewendetwerden.Auf Client-Seitewird im Prinzip nur eineAnwendungssoftware benotigt, die Bilddateninterak-tiv darstellenkann und die Benutzeraktionengeeignetaufnehmenund fur die server-seitige3DRendering-Anwendungcodierenkann.

Abbildung4.4:Remote3D Visualisierungmit einerRendering-Pipeline.

Die originalen3D Datenbleibenbei diesemKonzeptauf demServer und sinddemBenutzernicht direkt zuganglich.Fur kooperative Systemebedeutetdies eine zentraleDatenhaltung.DieVorteile diesesKonzeptesergebensich direkt ausdiesemUmstand,daßnun keineOriginaldatenmehralsKopiezumClient ubertragenwerdenund damitderSchutzvon UrheberrechtenunddieErfullung von Sicherheitsanforderungen erleichtertwird. Außerdemwird ein Systemauf Client-Seiteunabhangigvon speziellenHardware-und Software-Anforderungenfur das3D Rendering,dadort lediglich 2D Datenangezeigtwerdenmussen.Dadurchergibt sicheinehohereFlexibilit atfur denEinsatzauf einemweitenSpektrumvon Endgeraten,dasvom leistungsstarken PC, uberNotebooksbis hin zu PDAs (PersonalDigital Assistant) reichenkann.UbereinenRuckkanalzumServer findetdabeidie Interaktionmit den3D Inhaltenstatt.

Der Hauptnachteildieses Ansatzesist die Verzogerungszeit,die durch das Off-Screen-


RenderingunddieCodierungderBilder amServer bzw. die UbertragungderkomprimiertenBild-datenentsteht.AuchdurchdieDecodierungundAnzeigeamCliententstehtnaturlich nocheinmaleineVerzogerung.Die VerzogerungdurchRuckubertragungder Aktionen ist dagegenmeistver-nachlassigbar, dakeinegroßenDatenmengenverarbeitetwerdenmussen.AuchdieAnforderungenandie AuflosungderBilddatenkonnenzu einerunannehmbarenVerzogerungdesvisuellenFeed-backsfuhren.Bei diesemKonzeptmußdaherimmer ein KompromißzwischenBildqualitat undVerzogerungangestrebtundberucksichtigtwerden.


Eswurdenin denletztenJahrenmehrereSystemezur entfernten3D Visualisierungmit Hilfe vonImage-Streaming-Techniken vorgestellt.Engelet al. [ESE99] stelleneineRemoteVisualisierungs-Architektur fur Volumendatenim medizinischenBereichvor. Mittels einer verteiltenCORBA-AnwendungundeinergepuffertenUbertragungvon BilddatenstellensieeinemBenutzerdie fastvollstandigeInteraktionsfunktionalit at desOpenInventorAPI zur Verfugung,ohnedaßdie 3D Da-tenzumClient-Rechnerubertragenwerdenmussen.EswerdenverschiedeneBandbreitenin lokalenNetzenmit verschiedenenKompressionverfahrengetestetunddie Bildqualitat mit derBildwieder-holratein Verbindunggebracht.Die erzieltenBildwiederholratenlagenbei bis ª Bilder pro Se-kunde.Die dort vorgestellteArchitektur erlaubtauchdie AusweitungdesSystemsauf mehrereNutzer, diegemeinsameinzentralabgelegtes3D Modell visualisieren.Die AutorensprechenauchdenNutzendesAnsatzeszumSchutzderVertraulichkeit von medizinischenDatenan.

Haulsenund Jung[HJT98] stellenebenfalls ein Systemzur Kontrolle von entferntenvirtu-ellen UmgebungenuberBilddatenstrome und einenISDN-Ruckkanalvor. Hintergrundsind hierkooperative Anwendungenzur 3D Visualisierungvon Stadtentwicklungsdaten.Bei einerBildqua-lit at von «t¬tq�Nqt®t® Pixel (CIF-Format)erzielendieAutoreneineBildwiederholratevonmaximal ¯Bildern pro Sekunde.Zur Bildcodierungwurdeein Wavelet-basierterVideocodecverwendet.DieUmsetzungundUntersuchungeinereigenenRemote-Visualisierungs-Architektur wird vom AutordervorliegendenArbeit in [Loe00a] beschrieben.Dort wird ein MPEG-4Videocodec[Sik97] ver-wendet,umvisuelleObjekteigenschaftenin denBilddatenstromenbeiderUbertragungzuerhalten.Mit diesemSystemsoll erreichtwerden,daßBenutzermit Hilfe unterscheidbarer2D Objekteaufentfernte3D Objekteinteraktiv zugreifenkonnen.Die Testsin derprototypischenUmsetzungerga-ben,ahnlichwie in denobengenanntenSystemen,einehoheVerzogerungbei derVisualisierung.Die Bildwiederholratenlagenbei maximal q BildernproSekundebeieinerUbertragungsdatenratevon =qt® kBit/s.

4.4 Verteilte 3D Visualisierungfur kooperativeAnwendungen

Im vorhergehendenAbschnittwurdenSystemefur Einzelbenutzeranwendungen beschrieben,beidenendurchdie Verteilungder VisualisierungsprozesseeineKooperationauf Systemebenezwi-schenverschiedenenRechnernstattfand.Hiefur wurdedie BezeichungverteilteVisualisierungbe-nutzt. Brodlie et al. [BDG98] unterscheidendaruberhinauseineKooperationauf der Benutzere-bene,d.h.eineZusammenarbeitvon mehrerenMenschen,die ein verteiltesVisualisierungssystemverwenden.Dieswird hier in Anlehnungan[BDG98] alsVerteilte, kooperativeVisualisierungbe-zeichnet(vgl. Tabelle4.1). In diesemAbschnittsoll esnun um solcheMehrbenutzersystemezurverteilten3D Visualisierunggehen.Im Prinzip kommendabeidie beidenobengenanntenKon-zepteder lokalen3D Visualisierungmit Datenreplikationund der Remote3D Visualisierungmit


zentralerDatenhaltungzumEinsatz.Als zusatzlicheKomponentewird ein Mechanismuszur Syn-chronisationderverteilten3D DatenundderverschiedenenVisualisierungs-Pipelines dereinzelnenBenutzereingefuhrt. Systemkonzeptezur Synchronisationwahrendder3D Visualisierungwerdenim folgendendiskutiert.

Im wesentlichenbestehtein verteiltes,kooperativesVisualisierungssystemausmehrerenver-teilten Visualisierungs-Pipelines, die durch Austauschvon 3D Datenund Steuerungsparameternsynchronisiertwerden.DasZiel ist es,dieKooperationvonBenutzernmit einergemeinsamenDa-tenbasisdurchein synchronisiertesvisuellesFeedbackzu unterstutzen.In Abschnitt4.2.3wurdezwischeneinervollstandigenSynchronisation,beidersowohl dieNavigationin einer3D Szenealsauchdie Manipulationan denObjektenzu jedemZeitpunktfur jedenBenutzerubereinstimmen,undteilweiserSynchronisationunterschieden,bei dernur Objektmanipulationenangeglichenwer-den.WennauchErzeugungundLoschenvon Objektenin einervirtuellenUmgebungerlaubtsind,mussenin beidenFallenGeometriedatenundSteuerungsparameterubereinNetzausgetauschtwer-den.

In Abbildung 4.5 sind zwei Konzeptezur Realisierungvon Mehrbenutzersystemenmit loka-ler 3D VisualisierungundRemote3D Visualisierungdargestellt.Im linkenTeil derAbbildungistein Systemmit zwei Benutzerngezeigt,die durchDatenreplikationein 3D Dokumentauf ihrenRechnerubertragenhabenundnun jeweils einelokaleVisualisierungs-Pipelinebenutzen(LokaleVisualisierung- Multi-User ). Die Bilderzeugung,BilddarstellungundInteraktionpassiertalsolo-kal. Um nundie Kooperationmoglich zu machen,werdendie Benutzeraktionenvon Client 1 uberdie Systemgrenzenhinweg zu Client 2 ubertragenund umgekehrt. Dort werdensie dannjeweilsauf die 3D Datenangewendet.Im ErgebnissiehtjederBenutzeralle Aktionen,die in demverteil-tenSystemanden3D Datenvorgenommenwerden.In Abbildung4.5 ist die SynchronisationalsgestrichelterPfeil mit zweiSpitzen,deruberdieSystemgrenzenhinweggeht,dargestellt.

Abbildung 4.5: Multi-User-Visualisierung: Lokale Visualisierung (links) undRemote-Visualisierungmit individuellerNavigation(rechts).

Um mit einemsolchenSystemarbeitenzukonnen,mußnuneineAbstimmungderAktionenaufeinerhoherenEbenestattfinden.Dieskannz.B.durchVergabeeinesTokensgeschehen,derjeweilsnureinemBenutzererlaubt,dieDatenzuverandern.Alle anderenBenutzerkonnendanneventuellzwar nochautonomin derSzenenavigieren,aberkeineManipulationenderObjektemehrvorneh-men.Erst wennder privilegierte BenutzerdenToken freigibt, konnenandereTeilnehmerdiesen


erhalten.EineweitreichendeDarstellungvon Verfahrenzur AufrechterhaltungundSteuerungderKonsistenzvon verteilten3D Szenenin virtuellenkooperativenUmgebungenwird von SighalundZyda[SZ99]gegeben.

Um Remote3D Visualisierung mit zentralerDatenhaltungin einerverteilten,kooperativenAnwendungnutzenzu konnen,mussendie BenutzeraktionenzumServer ubertragenwerdenunddort synchronisiertauf das3D Modell angewendetwerden.Mit Hilfe der 3D Rendering-PipelineaufdemServerwerdenAnsichtendes3D Modellserzeugt,diedieseAktionenvisualisieren.Dabeider RemoteVisualisierunglediglich Bilddatenzum Client ubertragenwerden,wurdenin diesemFall alle Benutzerdie gleicheAnsichtdes3D ModellsalsvisuellesFeedbackbekommen.Es lasstsichdabeialsoauskonzeptionellGrundennur einevollstandigeSynchronisationrealisieren.WillmanaucheineunabhangigeNavigation zulassen,so mußdie Rendering-Pipelineam Server vorderKameratransformationaufgeteiltwerden.Dadurchwird dannfur jedenBenutzerausderselbenDatenbasiseineeigeneAnsichtmittelsseinerjeweiligenKameraparametererzeugtundzumClient-Rechnerubertragen.DieseMethodederteilweisenSynchronisationbei derRemoteVisualisierungkannmit einemSzenengraphkonzeptdurchperiodisches,synchronisiertesUmsetzenderKamera-parametererreichtwerden.In Abbildung4.5aufderrechtenSeiteist diesesKonzeptmit autonomerNavigationderClientendurchAufteilung derRendering-Pipelinein zwei Teil-Pipelines(RemoteVisualisierung - Multi-User - Indi viduelle Navigation) gezeigt.Der Server-Rechnerhat damiteineerhohteLast,daer im Fall von zwei Benutzernin einerZeiteinheitauchzwei AnsichtenunddiedoppelteBilddatenmengeerzeugenmuß.Fur � BenutzererhohtsichdieLastalsomaximalumdas � -fache,wennkeineRedundanzenbei derBilderzeugunggenutztwerden.WenneineUnter-gruppevon � BenutzereinegemeinsameNavigationwunschtunddie anderenBenutzerautonomnavigierenwollen, so lasstsich ein solchesSzenarioallerdingsrelativ einfach mit diesemKon-zeptumsetzen.Die Server-Last reduziertsichdementsprechend.Die in dieserArbeit beschriebeneSoftware-ArchitekturSCA3DnutztdasbeschriebeneKonzept,um einenserver-seitigenNavigati-onsraumfur dieVisualisierungvon3D Dokumentenzu realisieren.

Abbildung4.6:Multi-UserVisualisierung:Remote-Visualisierungmit vollstandigerSynchronisati-on.

In Abbildung4.6 ist eineverteiltes,kooperativesVisualisierungssystemmit vollstandigerSyn-chronisationgezeigt,das,wie obenbeschriebendie einfachsteGrundformdesRemoteVisualisie-rungskonzeptesdarstellt.BenutzeraktionenwerdenamServer synchronisiertundauf daszentrale3D Modell ubertragen.Es handeltsich dabeium Kameraparameterund Manipulationsparameter


dereinzelnenBenutzer. AusdiesenDatenunddemSzenengraphwird eineBildansichterzeugtundzuallenBenutzernubertragen.

Es wird schnellklar, daßein solchesSzenarionur mit einemprivilegiertenBenutzer, der dieNavigationleitet, sinnvoll funktionierenkann.Fur Gruppenanwendungen,wie z.B. virtuelle Klas-senzimmermit einemLeiterundeinerGruppevon Lernenden,kanndiesesKonzeptdahernutzlichsein.Die Moglichkeit zur Multicast-UbertragungderBilddatenunddie zentraleDatenhaltung,dieeinenSchutzder Datenin offenenInformationsraumenerlaubt,sind fur ahnlicheAnwendungenvonVorteil.


VerteilteVisualisierungsanwendungen fur mehrereBenutzerwurdenin den letztenJahreninten-siv untersuchtundesexistierenrelativ viele experimentelleSysteme.VielederAnwendungsfelderkommenausdenBereichenMedizin,Computer-Aided-Design(CAD) unddenNaturwissenschaf-ten wie Geowissenschaftenoder Chemie.Sehrviele der in der wissenschaftlichenLiteratur be-schriebenenSystemearbeitenmit demKonzeptder lokalenVisualisierungmit Datenreplikation.Die meistenverwendeneinenClient/Server-Ansatz,um die verteiltenDatenbanken konsistentzuhalten.Ein Beispielhierfur ist COVISE [RFL98], dasanderUniversitat Stuttgartentwickelt wur-de.Ein weiteresSystem,AVANGO [GLG00] vom Institut fur Medienkommunikationder GMD,arbeitetmit lokalenReplikationenund einemSzenengraphenkonzept (SGI Performer).Es ist furdieEntwicklungechtzeit-fahigerAnwendungenim BereichimmersivervirtuellerUmgebungenan-gelegt. Hesinaet al. beschreibenin [HSF99] ihr Systemmit demNamenDistributedOpenInven-tor, dasauf demOpenInventorAPI aufbautundeineserver-seitigeHauptkopiederverteiltenSze-nezur Synchronisationverwendet.Ein System,dasfur denEinsatzim Internetentwickelt wurdeundzur UnterstutzungderKooperationvon BenutzernauchAvatarebenutzt,ist dasDIVE-Systemvon Carlssonet al. [CH93]. Es basiertnicht auf einemClient/Server-Ansatz,sondernverwendetein Peer-to-Peer-Konzept,bei dem jederPeergleichberechtigtist und Aktionen uberMulticast-Gruppenversendetwerden.Esexistiert in diesemSystemalsokeinServer fur zentraleAufgaben.

Im Gegensatzzu derVielzahlvon Systemenmit lokalemVisualisierungskonzept sindAnwen-dungeneherselten,die reineRemote3D Visualisierungmit zentralerDatenhaltungamServer ver-wenden.Die HauptnachteilediesesKonzeptes,die sich ausder zentralenDatenhaltungund demvisuellenFeedbackdurchBilddatenubertragungergeben,sind einerelativ hoheVerzogerungszeitunddie linearmit jedemzusatzlichenBenutzeransteigendeServer-Last,wennautonomeNaviga-tion erlaubtseinsoll. Trotzdemlohnt sich die UntersuchungdiesesAnsatzesfur denzukunftigenEinsatzin Anwendungen,diezumeinenSicherheitsanforderungenbezuglichgeschutzter3D Datenanein verteiltesVisualisierungssystemstellenundzumanderendie Moglichkeitenzur SkalierungderBelastungder Benutzerrechnerbenotigen.Dahersollenzwei Systemevorgestelltwerden,diedasKonzeptderRemote3D Visualisierungfur dieKooperationmit 3D Dokumentennutzen.

Engel et al. [ESE99] beschreibenein Systemzur Remote3D Visualisierungmit Hilfe vonserver-seitigerzeugtenBilddatenstromen,diedurchdasRenderingvonmedizinischenVolumenda-tenentstehen.Die AktionenvondenTeilnehmerneinerVisualisierungskonferenz werdenubereineCORBA-SchnittstelleandenServer gesendetunddort aufeinenOpenInventor-Szenengraphen an-gewendet.Die UbertragungderBilddatenin codierterForm wird uberUDP Socket-Verbindungenrealisiert(sieheauchAbschnitt3.4.2).UberdenServer ist eineDatenbankmit denmedizinischenVolumendatenzugreifbar, sodaßmehrereBenutzereinenDatensatzauswahlenundgemeinsamvi-sualisierenkonnen.Die Benutzer-Softwarewird dabeilediglichzurAnzeigederBilddatenundzurEingabevonAktionenverwendet.


Ein prototypischesSystemzur Remote3D VisualisierunguberBilddatenstromewird vom Au-tor in [Loe00a] vorgestellt.In Abschnitt4.3.2wurdedasSystemschonkurz angesprochen.DasKonzeptwird alsVisualInteractionApproach (VIA) bezeichnet,daeinBenutzeruber2D Informati-onmit angereicherterObjektinformation,wie Objektkonturenund-texturen,mit denserver-seitigen3D Objektenarbeitet.Auch hier konnenmehrereBenutzerzusammenarbeitenund dabei3D Do-kumenteauseinerDatenbankvisualisieren.Allerdings wurdekeineMoglichkeit zur autonomenNavigationin dasSystemintegriert, daderHauptaspektin derUntersuchungderobjekt-basiertenvisuellenInteraktionlag.DadurchmußeseinenprivilegiertenBenutzergeben,derdie Navigationleitet.DasprototypischeSystemwird in Kapitel7 nocheinmalkurzdiskutiert.

4.5 Kombination von lokalemund Remote-Renderingfur verteilte 3DSzenen

Um dieVorteilederlokalenundderRemote3D Visualisierungin verteiltenAnwendungenzukom-binierenund die NachteileeinessolchenSystemszu minimieren,werdenin aktuellenUntersu-chungen,die in diesemAbschnitt vorgestelltwerden,beideKonzeptekombiniert.Um z.B. diePerformanzeinesspezialisiertenHigh-End-Graphikrechnersfur sehrkomplexe 3D Datennutzenzukonnen,wird dieserubereinNetzwerkalsRemote-Visualisierungs-Server verwendet.DamitderBenutzerabergleichzeitigubereinehoheBildwiederholratebei der Manipulationvon Einzelob-jektenverfugt,werdendieseObjektelokal auf seinemRechnergerendertunddannmit derserver-seitigevisuellenInformation in einerSzeneangezeigt.Dadurchwird esmoglich, die BelastungeinesClientszu skalieren,3D Dokumenteflexibel zu schutzenunddie Netzlastandie verfugbareBandbreiteanzupassen.Zudemwird eineweitesSpektrumvon Synchronisationsmoglichkeiten furdieverteilte3D Visualisierungin kooperativenAnwendungenmoglich.

Abbildung4.7:Kombinationvon lokalerundRemote-Visualisierungfur einenBenutzer.

In Abbildung4.7 ist eineMoglichkeit fur ein kombiniertesKonzeptanhandderin diesemKa-pitel verwendetenSymbolegezeigt.Die 3D Szene,die sichanfangsauf demServer befindet,wirdwahrendderVisualisierungin eineserver-seitigeSzene°,± undeineclient-seitigeSzene ²°A± auf-geteilt. Die Client-Szeneenthalt nebendenubertragenen3D Objektenfur die lokale Interaktionauchnocheine2D Projektionsflache,auf die die server-seitigevisuelleInformationalsTextur ab-


gebildetwird. Der Benutzersiehtauf dieseWeiseeineSzene,die auseinemHintergrundbildvomServer unddenlokalen3D Objektenim Vordergrundzusammengesetztist. DurchSynchronisationderVisualisierungs-PipelinesaufdemServerundaufdemCliententstehteineinheitlichervisuellerEindruckder Gesamtszene,die demoriginalen3D Dokumentam Server entspricht.Die Benut-zeraktionenwerdensowohl auf die Client-Szenealsauchauf die server-seitigeSzeneangewendet.Uberdie Systemgrenzehinweg werdendabei3D Daten,BilddatenundKontrollparameterubertra-gen.

In Abbildung4.8 ist dasobenabstraktdargestellteKonzeptnunausfuhrlicherdargestellt.DieAusgangsszenewird hierbeiin eineServer-SzeneundeineClient-Szeneunterteilt.DurchSynchro-nisationder beidenVisualisierungs-Pipelines amServer und amClient entstehtein visuellerEin-druck der Gesamtszene.Der LoI-Regler (Level-of-Information)kontrolliert dabeidie VerteilungderSzenenunddieReprasentationsformeinesObjektes,dasubertragenwird. DieserAnsatzist dieGrundlagefur dasKonzeptderSkalierbarenSzenen.

Abbildung4.8:KombiniertesSCA3D-Konzeptmit dynamischerVerteilungderOriginalszene.


KombinierteAnsatzesindaktuellerGegenstandderForschungundsindin derLiteraturnochnichtzahlreichvertreten.Hier sollenzwei Systemeerwahntwerden,die lokaleund Remote3D Visua-lisierungfur denEinsatzin verschiedenenBereichenkombinieren.Engelet al. [EHTE00] kom-binierenserver-seitigesmit client-seitigemRendering,um komplexe medizinischeVolumendatenfur denbreitenEinsatzim klinischenUmfeld interaktiv visualisierenzu konnen.Auf Server-Seitekommtein OpenInventor-SystemzumEinsatz,wahrendauf Client-Seiteein Java3DRendererundein Java2D Viewer verwendetwird. MehrereSzenarienzum Einsatzin der Praxiswerdendisku-tiert unddieEntwicklungvonkombiniertenAnwendungskonzeptenwird alssehrvielversprechendbezeichnet.Verteiltekooperative Visualisierungwird in demArtikel nicht thematisiert.

Ein Konzeptzur Navigationin entferntenvirtuellenUmgebungendurchBilddatenubertragungwird vonMannundCohen-Or[MCO97] beschrieben.Dabeiwerdenzur Reduzierungderbenotig-tenDatenubertragungundderBildaktualisierungsratenur diejenigenBildbereicheneuvom Servergesendet,die sich bei der Navigation starker veranderthaben.Am Client befindetsich lediglich


eineGeometriebasis,die zur vollstandigenVisualisierungmit Texturbildernvom Server gerendertwird. DurchUbertragungvonReferenzansichtenundExtrapolationvonBildbereichenwird dervi-suelleEindruckbei derNavigationam Client aufrechterhalten,bis aktualisierteTexturbildervomServergeliefertwerden.DieserkombinierteAnsatzist vor allemfur komplexe virtuelleWeltenaufeinemServervonVorteil, dieentferntvisualisiertwerdensollen,wobeidieNetzlastgeringgehaltenwerdenmuß.Die ErweiterungdesAnsatzesfur kooperative Anwendungenwird von denAutorenebenfalls nichtnichtdiskutiert.

Die Software-ArchitekturSCA3D, die in den folgendenKapiteln vorgestelltund untersuchtwird, stellt die dynamischeErweiterungeineskombiniertenAnsatzesfur verteiltekooperative Vi-sualisierungssystemedarundgehtdamituberdenStandderaktuellenTechnikhinaus.

Kapitel 5

Verteilte VisualisierungmitSkalierbarenSzenen

Nachdemin denvorigenKapiteln die Grundlagen,Methodenund der Standder ForschungzumThemaverteilteVisualisierungvon3D Dokumentenerlautertwurde,wird nuneineigenesKonzeptvorgestellt,dasmit einerKombinationvon lokalemund Remote-Renderingarbeitet.DasKapitelbeginnt mit einerEinfuhrungin dasPrinzipderSkalierbarenSzenen.Dannwird eineEinordnungin denStandder Forschunggegeben,gefolgt von einerdetailliertenBeschreibung desKonzeptesmit seinenwichtigstenKomponenten.Im weiterenwird dannauf dasManagementvon Sicher-heitsinformationenunddasKooperationsmodellim KonzeptderSkalierbarenSzeneneingegangen.Die Realisierbarkeit einesdynamischenVerhaltensder auf dem KonzeptbasierendenSoftware-Architekturwird im AnschlußdiskutiertundeineZusammenfassungschließtdanndasKapitelab.

5.1 Einf uhrung: DasPrinzip der Skalierbaren Szenen

Das Konzeptder Skalierbaren Szenenstellt eine Losung fur die verteilte Visualisierungvongeschutzten 3D Dokumentenunter Berucksichtigungvon Anbindungund Leistungder Benut-zerrechnerin heterogenenUmgebungendar (siehe[LF01]). Das Konzeptnutzt einenLevel-of-Information Ansatz, der 3D Objekte in verteilten Informationsraumenin Form von Reprasen-tationenmit variablemGehaltan Information verwendet.Dazu wird die Originalszenein eineServer-SzeneundeineClient-seitigeSzeneaufgeteilt,zwischendenenObjektreprasentationenaus-getauschtwerdenkonnen.Eswird zwischendemNavigationsraumaufServer-SeiteunddemInter-aktionsraumaufClient-Seiteunterschieden,in denensichjeweilsdieObjektreprasentationen befin-den.DurchKombinationvon Remote3D Visualisierungim Navigationsraumundvon lokaler3DVisualisierungim Interaktionsraumentstehtder EindruckeinerGesamtszenewahrenddesArbei-tensmit einem3D Dokument.DazuwerdendieVisualisierungsmoduleaufServer- undClient-SeitesynchronisiertunddieBilddatenvom ServeralsTextur in die lokaleSzenedesClientseingefugt.

Die Verteilungder Visualisierungsprozesse und der Objektreprasentationen wird durch eineSchieberegler-Funktionalit at gesteuert.Der Level-of-Information-Schieberegler (LoI-Regler) kannentwedervom Benutzerselbsteingestelltwerden,wobeibestimmtePositionendurchdie Randbe-dingungengesperrtseinkonnen,oderer wird durchein speziellesProtokoll automatischgeregelt,wobeidie aktuelleRechtesituationunddie LeistungdesjeweiligenClientsberucksichtigtwerden.Hierdurchkanndie Software-Architektur SCA3D, die dasKonzeptderSkalierbarenSzenenreali-siert,sich automatischan die RandbedingungeneinerheterogenenUmgebung anpassen.Die An-

72

KAPITEL 5. VERTEILTE VISUALISIERUNG MIT SKALIERBAREN SZENEN 73

passunggeschiehtdurchdieWahleinesentsprechendenLevel-of-InformationundeinergeeignetenAuflosungfur jedesbearbeiteteObjekt.In Abbildung5.1sinddieverschiedenenKomponentendesKonzeptesdargestellt.MehrerBenutzersindmit einemVisualisierungs-Server verbundenundar-beitenmit einem3D Dokument,dassichanfangskomplettauf demServer im Navigationsbereichbefindet.DurchSelektionkonnenObjektein denlokalenInteraktionsraumeinesClientsubertragenwerden.

Abbildung5.1:DasKonzeptderSkalierbarenSzenen.

Mit demLevel-of-Information-SchiebereglerkannaufClient-Seitekontrolliertwerden,welcheObjektreprasentationen im Interaktionsbereich, alsoauf demlokalenRechnerdesBenutzers,furselektierteObjekteexistieren.Ein ObjektkanndurchdasOriginal,durchein polygonales3D Netzmit einerbestimmtenAuflosung,durchBounding-BoxInformationoderdurchreineBildinforma-tion zumClient ubertragenwerden.JenachObjektreprasentationwird einegeeigneteRendering-Methodeangewendet.DurchdiesenAnsatzergebensichfolgendeVorteile:� IPR Management: Die geistigenEigentumsrechtefur 3D Objektekonnengeschutzt werden,

dadieGeometriekontrolliertundstufenweiseubertragenwird.� Komplexitats und Lastmanagement: Durch die Aufteilung in Teilszenenund VerwendungverschiedenerReprasentationenvon Objektenkanndie VisualisierungslastzwischenClientundServer verteiltwerdenunddie Ubertragungsratereguliertwerden.� Zusammenarbeit: KooperationmehrererBenutzerist moglich, wobeimit unterschiedlichenReprasentationender3D DokumenteamClient gearbeitetwerdenkann.DurchGenerierungvon entsprechendenBilddatenamServer konnensynchronisierteoderjeweils eigeneBlick-positionenrealisiertwerden,sodaßentwederalle Benutzergemeinsamnavigierenodersichselbstandig in der Szenebewegen.Dabeiwerdendie Objekteim Interaktionsraumentspre-chendsynchronisiert.


5.2 Vergleichmit vorhergehendenArbeiten

In Abschnitt4.5 desvorhergehendenKapitel wurdenAnsatzezur Kombinationvon lokalemundRemote3D Renderingdiskutiertund Beispielein der Literaturbeschrieben.In diesemAbschnittsoll eineEinordnungdesAnsatzesder SkalierbarenSzenenin denStandder Technikvorgenom-menwerden,wobeidie jeweilsangestrebteProblemlosungeinesAnsatzesalsBezugskriteriumver-wendetwird. Ein Vergleich mit vorhergehendenArbeitenausder Literatur soll dabeihelfen,diejeweiligenZielederbekanntenAnsatzezuverdeutlichen.

Die Hauptaspekteder in dieserArbeit vorgestelltenSoftware-Architektursinddie verteilte3DVisualisierungvon geschutztenDokumentenund die Skalierbarkeit der benotigten Informations-mengeam Client fur kooperative Systeme.Dabei wird ein besonderesAugenmerkauf die An-forderungenbeim verteiltenArbeiten mit 3D Dokumentenin offenenInformationsraumen,wiedigitalenBibliotheken,gelegt. DieseAnforderungenerforderneineBerucksichtigungvon Sicher-heitsaspekten,NetzbandbreitenundlokalerRechnerleistung.Ein Anwendungsszenariofur heutigeSysteme,dasauchzukunftigeEntwicklungenderInformationstechnologie miteinbezieht,kannvoneinerrelativ schnellsteigendenClient-Leistungundeinerrelativ langsamenVerbesserungderNetz-anbindungbzw. weiterhinhohenAnbindungskostenin den nachtenJahrenausgehen(siehez.B.[MCO97]. Die folgendeAuflistungderverschiedenenArbeitenbzw. Anzatzebeschreibtdie Kon-zepteanhandder angestrebtenProblemlosung,der Randbedingungenbzw. VoraussetzungenunddesjeweiligenAnwendungsgebietes.Da in derLiteraturbishernur sehrwenigeSystemebeschrie-benwurden,dieeinenkombiniertenAnsatzverfolgen,werdenhierzweibekannteArbeitenmit demeigenenAnsatzverglichen.

In derArbeit von Engelet al. [EHTE00] werdenlokaleundRemoteVisualisierungstechnikenfur interakti vesverteiltesVolumen-Renderingkombiniert:� Problemlosung: Reduzierungder Client-Last,Ausnutzungvon speziellenHardware- und

Software-Komponentenin einerheterogenenUmgebung.� Randbedingungen: Starker, spezialisierterServer-Rechner;schwache oder Standard-PC-Client-Rechner;lokalesNetz (LAN: 34 MBit/s TCP/IP);keineSicherheitsaspekteberuck-sichtigt.� Anwendungsbereich: MedizinscheVolumendaten,interaktive Visualisierungkomplexer Da-tenim klinischenEinsatz.

Die Arbeit vonMannundCohen-Or[MCO97] verwendetentferntgerenderteTexturen,dieaufeineeinfache,lokaleBasisgeometrieabgebildetwerden,um Benutzerndie Remote-Navigation inkomplexen,virtuellen 3D WeltenaufeinemServer zuermoglichen.� Problemlosung: ReduzierungderNetzlastbeiderentferntenNavigationin virtuellenWelten;

ReduzierungderlokalenVerzogerungdurchBildextrapolationbeiderNavigation.� Randbedingungen: starkerServer;schwacheroderStandard-PC-Client;begrentzteBandbrei-te derNetzanbindung.� Anwendungsbereich: RemoteNavigation in virtuellen Weltenim BereichdesWorld-Wide-Web.


Nun soll im Vergleich dashier untersuchteKonzeptder SkalierbarenSzenenanhandder ge-nanntenKriterieneingeordnetwerden.DerAnsatzsoll, wie obenbeschrieben,dasverteilte Arbei-ten mit 3D Dokumentenin offenenInformationsraumenunterstutzen:� Problemlosung: DynamischerAusgleichvon Client- und Server-Last; dynamischeAnpas-

sungder Netzlastan die verfugbareBandbreite,indem die globaleVerzogerungszeitlau-fend ausgewertetwird und derServer mit dementsprechendangepaßtenDatenratensendet;Berucksichtigungvon Sicherheitsaspekten;Kooperationin heterogenenUmgebungen.� Randbedingungen: Server-Rechnermit unterschiedlicherLeistung;Client-Rechnermit un-terschiedlicherLeistung;variableAnbindungsbandbreiten verschiedenerClients;geschutzteDaten.� Anwendungsbereich: Software-Architekturzum verteilten Arbeiten in offenen Informati-onsraumen;verteilteVisualisierunggeschutzter 3D Dokumentein Digitalen Bibliotheken;Kooperationmit 3D Dokumenten.

Aus diesemVergleichderverschiedenenAnsatzegehthervor, daßzumeinendie RegulierungderClient-Lastbeider3D Visualisierungmit gleichzeitigerhoherQualitat undInteraktionsrateeinzentralesZiel beiderVerwendungvonkombiniertenbzw. hybridenKonzeptenist.Die LeistungvonServer-RechnernspieltebensoeinewichtigeRolle,da in vielenFallenDienstevon spezialisiertenHochleistungsrechnern von entferntenClient-Rechnernnutzbargemachtwerdensollen.Dabeiistebenfalls die ReduzierungderNetzlastin Umgebungenmit niedrigenundbegrenztenBandbreitenvonBedeutung.

DieHerausstellungsmerkmaledesKonzeptesderSkalierbarenSzenenin wissenschaftlicherundtechnischerHinsicht sind vorallem der dynamischeAspekt,der durch den Level-of-InformationAnsatzzusammenmit derSchiebereglerfunktionalitat in dasKonzeptintegriert wird, unddie ent-haltenenMoglichkeiten zum Managementvon geschutztenDaten.Sowohl die dynamischenAn-passungder Client- und Server-Last,als auchdie dynamischeRegulierbarkeit der NetzlastdurchVerwendungvon Objektreprasentationen mit variablemInformationsgehaltsind neueAspekteinder Entwicklung hybrider Visualisierungsysteme.Die Skalierbarkeit der InformationsmengeamClient-Rechnerund die sich darausergebendenVorteile fur kooperativesArbeitenmit 3D Doku-mentensindweiterePunkte,die in derwissenschaftlichenLiteraturnochnicht untersuchtwordensind.

5.3 DasKonzeptder Skalierbaren Szenenin der Gesamtubersicht

In diesemAbschnittsoll ein Uberblick desKonzeptesder SkalierbarenSzenengegebenwerden,indemallewichtigenKomponentenerlautertwerden.DasZiel desKonzeptesist dieUnterstutzungdesverteiltenArbeitensmit 3D Dokumentenin offenenInformationsraumen,die Informations-Server undBenutzer-Rechnerumfassen,durcheinenkombiniertenVisualisierungsansatz. Zur Vi-sualisierungder3D Dokumentewird zwischeneinemNavigationsraumamServerundeinemInter-aktionsraumamClient unterschieden,die ubereineMiddleware-Schnittstellesynchronisiertwer-den.DieseSchnittstellewird in demvorgestelltenKonzeptals Level-of-Information-Raum(LoI-Raum)bezeichnet,dadieSynchronisationuberInterface-Objektestattfindet,die sichin einemvir-tuellenRaumzwischenNavigationsraumundInteraktionsraumbefinden.ZwischendemNavigati-onsraumunddemLoI-RaumaufServer-Seiteist ein Filter fur Objektreprasentationen(IPR-Filter)


eingefugt, derdafur sorgt, daßnur Objektreprasentationen zu denBenutzerngelangen,fur die sieentsprechendeRechtebesitzen.In Abbildung5.2ist dasGesamtsystemdesKonzeptesderSkalier-barenSzenengezeigt.� Navigationsraum: Virtueller Raumauf demServer, in demsichdie server-seitigeSzenebe-

findetundworin einBenutzerdurchRemoteVisualisierungnavigierenkann.� Interaktionsraum: Lokaler 3D Visualisierungsraumder Benutzeranwendung,in dem dieTransformationenund die Beleuchtungssimulation der client-seitigenSzeneund die lokaleBenutzerinteraktiondurchgefuhrt wird.� LoI-Raum: Virtueller Raum am Server, in dem sich die Interface-Objektefur selektierte3D Objektebefinden.Er ist ubereineMiddleware-Schnittstellevom Client auszuganglich.DurchdenIPR-Filterkonnennur erlaubteObjektformenuberdenLoI-RaumzumBenutzergelangen.

Abbildung5.2:GesamtubersichtdesKonzeptesderSkalierbarenSzenen

Die OriginalszeneauseinerDatenbankwird am Server in eineserver-seitigeSzeneund eineclient-seitigeSzeneaufgeteilt.Die client-seitigeSzeneenthalt alle Objekte,die sich im Interak-tionsbereichbefindenundzusatzlicheineProjektionsflachefur die remote-visualisierten Ansichtender3D SzenevomServer. Eswird zwischendreiZustandenfur 3D Objekteunterschieden,namlichinaktivenServer-Objekten, aktivenObjektenund inaktivenClient-Objekten. In derfolgendenAuf-listungwerdendiedreiZustandenaherbeschrieben:� inaktivesServer-Objekt: Wenn ein 3D Dokumentam Server in dasVisualisierungssystem

geladenwird, befindensichzunachstalle seineObjekteim Navigationsbereichundkonnen


vom Benutzernur entferntvisualisiertwerden.Die Objektebefindensich fur dasSystemdannim Zustandvon inaktivenServer-Objekten.� aktivesObjekt: Sobaldein Benutzerein Objekt selektiert,wird ein Interface-Objektdieses3D Objektesim LoI-Raumerzeugt,mit demeineVerbindungzwischenClient und Serverentsteht.DasselektierteObjektbefindetsichdannnochauf demServer, abergleichzeitigistam Client eineObjektreprasentationvorhanden.DasObjekt befindetsich dannim aktivenZustandundeinBenuzterkannvielfaltigeAktionenaufdemObjektausfuhren.� inaktivesClient-Objekt: Wenn ein Benuzterdie Rechtebesitzt,dasOriginal einesserver-seitigenObjektesausdem3D DokumentzuerwerbenunddiesesObjektzumClient-Rechnerubertragenwordenist,dannwird dasOriginalobjektin derServer-Szeneentfernt.DasObjekt,dassichnunlokal beimClientbefindet,ist fur dasSystemim ZustandeinesinaktivenClient-Objektes.Auch Objektreprasentationen, die nicht demOriginal entsprechen,konnendurchAbkopplungvomServer zu inaktivenClient-Objektengemachtwerden.

In Abbildung5.2 ist dasSystemmit einem3D Dokumentgezeigt,dasgeradebearbeitetwird.Zwei Objektebefindensichim Zustandvon aktivenObjektenundein Objekt,namlichderWurfel,ist im Zustandeinesinaktiven Server-Objektes.Fur die aktiven Objekteexistiert ein Interface-Objekt im LoI-Raum und jeweils eine Objektreprasentationim Interaktionsbereich. Im Fall derKugelist dieseinniedrig-aufgelostes 3D Netzundim Fall desanderenObjekteshandeltessichumeinSubdivision-Surface-Modell, dasdurchUbertragungvonzusatzlichenParameterwertenschritt-weiseandie OriginalformamServer angeglichenwerdenkann(SubdivisionSurfaces, sieheLoop[Loop87] oderMuller undHavemann[MH00]).

ZwischenClient undServer werdenwahrenddesArbeitensfortwahrendNachrichten(SCA3DNachricht) mittels einesfestgelegtenProtokolls ausgetauscht,die denaktuellenZustandder Ob-jekteundderVisualisierungsanwendungenamClient undamServer im Systembekanntmachen.DieseNachrichtenenthaltenjeweils vier Informationsblocke, namlich uberdasjeweils angefrag-te Objekt, die beabsichtigteAktion auf diesemObjekt,die Leistungbzw. Gute einesTeilnehmer-Rechnersund schließlichuberdie aktuelleRechtesituationzwischenClient und Server in FormeinerRechtesignatur. Die Client-Anwendungenthalt eineSchiebereglerfunktionalit at undein ent-sprechendesgraphischesSchieberegler-Interface(Level-of-Information-Schieberegler), mit demeinBenutzerwahlenkann,welchenGraddesInformationsgehalteser mit einerObjektreprasentationubertragenbekommenmochte.Die erlaubtenPositionendesSchiebereglershangenvon derRech-tesituationdesBenutzersab. Auchdie LeistungeinsClient-RechnersundseineAnbindungandenServer werdenzur Kontrolle desLoI-Schiebereglersherangezogen,indemungunstigePositionenbewertetund markiertwerden.Die Gute einesClient-Rechnerswird mit Hilfe einerPerformanz-metrik am Client bestimmt.Die ermittelteGute wird als skalarerZahlenwertim Systembekanntgemachtund regelmaßigaktualisiert.Im weiterenwerdendie nochfehlendenKomponentendesSystemsausAbbildung5.2beschrieben.� SCA3DNachricht: VierseitigeNachrichten,die deminternenKommunikationsprotokoll des

Systemsentsprechen,undAuskunftuberObjekte,Aktionen,dieGuteeinesClient-RechnersunddieRechtesituationbeieinerInteraktiongeben.� Level-of-Information-Schieberegler: Funktionalitat derClient-Anwendung,die die Regulie-rung desInformationsgehaltesvon ubertragenenObjektenerlaubt.Die PositionendesLoI-Schiebereglers gebenan, in welcherForm ein Objekt in den Interaktionsraumubertragenwird.


� Performanzmetrik: Im SystembekannteMetrik, dieeinenVergleichderLeistungundAnbin-dungvon verschiedenenClient-Rechnernermoglicht. Die Gutewird amClient durchMes-sungenundanhandderPerformanzmetrikbestimmt.

Die FreigabeundBewertungvonPositionendesSchiebereglerswerdenim Systemautomatischvorgenommen,sodaßdie Benutzerwahl jederzeitdenRandbedingungenderUmgebungangepaßtist. Bei einerVollautomatisierungderKontrollewird jeweils die optimaleReglerpositionvom Sy-stemfur einenBenutzergewahlt.Dieswird im Abschnitt5.8besprochenunderlaubtein adaptivesVerhaltendesSystemsdurchdynamischeKontrolledesSchiebereglers.In denfolgendenAbschnit-tenwerdendieeinzelnenKomponentenundihreModellierungnaherbeschrieben.

5.4 Der Level-of-Information Ansatz

In diesemAbschnittwird derLevel-of-InformationAnsatz,derzentraleBedeutungfur dasKonzeptderSkalierbarenSzenenhat,vorgestelltundnahererlautert.Der Ansatzberuhtauf derGrundidee,daßin einerverteiltenvisuellenMehrbenutzerumgebung eineMoglichkeit zur Anpassungder In-formationsmengefur jedenClient an seinelokalenGegebenheitenund Anforderungenbestehensollte. Sowohl die lokale Leistungund Anbindung,als auchder vom Benutzeraktuell verlang-te Detaillierungsgradder Informationsollenvon einemverteiltenSystemberucksichtigtwerden,um dasArbeitenin heterogenenMehrbenutzerumgebungen optimalzuunterstutzen.Der Level-of-InformationAnsatzsetztdieseIdeeum, indemfur 3D Dokumenteund ihre ObjekteverschiedeneReprasentationenbzw. Formenfur dasverteilteArbeitenangebotenwerden.Wie in Kapitel3, Ab-schnitt3.1 schonangesprochen,kannein 3D Objektauf verschiedeneWeisebeschriebenwerden.Fur geometrischeObjekte,die implizit durchAngabevon Operationenund Parametermodelliertwerden,existiereneineAnzahlvon Reprasentationsformen,die alle dasgleicheObjektdarstellen,abereinenunterschiedlichenGehaltan Informationuberdie Geometrieenthalten.Die SkaladerBeschreibungsartenvon 3D Objektenreichtvon derexaktenparametrisierten3D Form,uberpoly-gonale3D Netzebishin zureinerBildinformation.Fur dasArbeitenmit diesenObjektenin Visuali-sierungsumgebungensindalledieseFormenfur bestimmteAufgabenbereichegeeignet.Daherliegtesnahe,alleObjektformenaufdieserSkalain einerverteiltenSoftware-ArchitekturzuunterstutzenunddamiteinhohesMaßanFlexibilit at beimArbeitenmit 3D Dokumentenzuermoglichen.

Abbildung5.3:Objektreprasentationenvon3D Objektenmit variablemGehaltanInformation.


Aus denvorhergenanntenGrundenundAnforderungen,die die lokaleRechnerleistung,Netz-anbindungoderSicherheitsaspektevon Originaldatenumfassen,bietetdie Interaktionmit denOri-ginalobjektenuberObjektformenmit geringeremInformationsgehaltoft Vorteile.Dies wird vomLevel-of-InformationAnsatzermoglicht, indemdie Originaldateneines3D Objektesauf demSer-ver bleibenundderBenutzerfur einzelneObjekteverschiedeneObjektreprasentationen anfordernkann,die dannzu ihm ubertragenwerden.Solangedie Objektreprasentationin einemaktivenZu-standist, bleibt siedabeimit ihrem Original amServer verknupft. In Abbildung5.3 ist die Skalader Objektformenmit einemvariablemGehaltan Informationgezeigt,die von der exaktenpara-metrisiertenReprasentationbiszur reinenBilddatenreprasentation in FormeinerTextur reicht.FurjedenLevel existierenverschiedeneAuflosungsgrade,die z.B. durchdie Maschengroßebei Drei-ecksnetzenoderdieBildauflosungbeiBildobjektenbestimmtwerden.

Aufbau einer Client-Szene

DurchdenZugriff aufOriginalobjekteamServer uberverschiedeneObjektformenkonnendieAn-forderungenverteilterUmgebungenflexibler erfullt werden.Ein Benutzer, derlediglicheinenrela-tiv schwachenRechnermit einerlangsamenAnbindung,z.B. uberein Modem,besitzt,wird nichteinevollstandigeKopiedeskomplexen3D Dokumentes,mit demer geradearbeitet,auf seinenlo-kalenRechnerubertragenwollen.Wennernunmit einemTeildokumentarbeitet,daserin niedrigerAuflosungbenotigt, wird er eineentsprechendeKopiediesesTeildokumentsanfordern,die er mitseinenlokalenRandbedingungenkomfortabelbearbeitenkann.Die ubrigeInformationdeskom-plexen Dokumenteswird ubereineregelmaßigenAktualisierungeinesHintergrundbildesmittelsRemote-Visualisierungzuganglichgemacht.Zu diesemZweckenthalt die Client-SzeneeinePro-jektionsflachefur Texturen,dievomServer geliefertwerden.In Abbildung5.4ist dieClient-SzeneeinesBenutzersschematischmit ihremjeweiligenSzenengraphengezeigt.

Am Beginn einerVisualisierungssitzungenthalt die Client-Szenenur die 2D Projektionsflachefur die Remote-Visualisierungdesserver-seitigen3D Dokumentes(Abbildung 5.4: linke Seite).Hier ist das3D DokumentalseinzelnesObjekt in Form einesBildobjektesamClient zuganglich.DerBenutzerkannnundurchSelektionvonEinzelobjektenoderObjektgruppenaufseinemDisplayObjektein verschiedenenFormenanfordern,die dannvom Systemin seinelokaleSzeneintegriertwerden.In derMitte von Abbildung5.4 sindzwei ObjekteausdemBildhintergrundherausgelostundin die Client-Szeneintegriert worden.EinezusatzlichelokaleLichtquellesorgt dafur, daßdielokaleVisualisierungsinnvolle Ergebnisseliefert, falls keineLichtquellenmitubertragenwurden.Wennder Benutzernun in der Gesamtszenenavigiert, werdender Bildhintergrund und die Vor-dergrundobjektesynchronisiert,sodaßein visuellerGesamteindruckentsteht.SobaldderBenutzerdasgesamte3D DokumentalsKopiedesOriginalsauf seinenRechnerubertragenhat,wird keineHintergrundinformation vom Server mehrbenotigt unddie gesamteVisualisierunggeschiehtlokal(Abbildung5.4: rechteSeite).

Die UbertragungvonObjektreprasentationenwird, wie obenangedeutet,vomBenutzerinitiiertund vom Server durcheinePush-Operationausgefuhrt. Dadurchwird der Zugriff auf unerlaubteObjektdatenunmoglichgemacht.DerLoI-Schieberegler steuerthierbeidenInformationsgehaltderubertragenenObjektform.


Abbildung 5.4: Reprasentationeines3D Dokumentesauf Client-Seiteals Bildobjekt (links), alsKombinationaus3D- undBildobjektenundals3D Gesamtszene.

5.5 Modellierung von Navigations- und Interaktionsraum mit einemDocument-Request-Broker-Ansatz

In diesemAbschnitt soll die Modellierung der im Konzeptder SkalierbarenSzenenenthalte-nenNavigations-undInteraktionsraumevorgestelltwerden.In Abschnitt5.3 wurdeerlautert,daßfur aktive 3D Objekteein Interface-Objekterzeugtwird, dassich in einemvirtuellen Level-of-Information Raumbefindet.DieseInterface-Objektedienendazu,dem Benutzerden indirektenZugriff auf die geschutztenserver-seitigen3D Objektezu ermoglichen.NebenderErzeugungvonneuenObjektreprasentationen wird auchdie Manipulationund Transformationvon 3D Objektenauf demServer mit Hilfe der Interface-Objekterealisiert.Die Interface-ObjektestellenMethodenfur denZugriff aufObjektdatenzurVerfugung,aufdie eineClient-AnwendungubereinReferenz-objekt zugreifenkann.Die Referenzobjektewerdenim Document-Request-Broker AnsatzdurchdieObjektreprasentationen deraktiven3D ObjektezurVerfugunggestellt.

Dasin Kapitel 2 vorgestellteSzenengraphkonzeptfur 3D Dokumente,dasvon vielenmoder-nenVisualisierungsanwendungen unterstutzt wird, legt esnahe,verteilte Interaktionmit 3D Do-kumentenubereineallgemeineVermittlungsschichtumzusetzen,die zwischender Anwendungs-undMiddleware-Schichtliegt.DieseVermittlungsschicht,die im folgendenalsDocument-Request-Broker bezeichnetwird, arbeitetmit Interface-ObjektenaufServer-Seitebzw. ObjektreferenzenaufClient-Seiteund ahneltdamit demAufbau einerobjekt-orientiertenMiddleware-Architektur, wiez.B.CORBA.

In Abbildung5.5ist dieSystemmodellierungmittelseinerVermittlunsgschichtfur verteilteOb-jektanfragen,demDocument-Request-Broker, dargestellt.Auf untersterEbenelaufenalle objekt-orientiertenMethodenaufrufeuber die verwendeteMiddelware. Oberhalbdieser Middleware-


Abbildung5.5: KonzepteinerDocument-Request-Broker Architekturfur objekt-orientierteDoku-mentmodelle.

Schichtist nun abereineSchichtzur Kontrolle desDokumentesauf demServer und desdazu-gehorigenDokumentesaufClient-Seiteeingefugt.Alle OperationendievomBenutzeraufdasbear-beiteteDokumentangewendetwerden,werdenmittelsderDokumentkontrolleaufServer-SeiteundClient-Seitesynchronisiert.Dadurchwird fur aktiveObjekteeineVerknupfungzwischenClientundServeraufrechterhalten.Auf dieseWeisewird auchdieSynchronisationderBenutzernavigationimGesamtsystemermoglicht.

Auf derAnwendungsebenewerdenfur alle Objekte,die vom BenutzerdurchSelektionin denaktivenZustandgebrachtwurden,Interface-Objekteerzeugt.Mit derErzeugungwird gleichzeitigeineObjektreprasentationalsReferenzobjektzumClient ubertragen.Die Aktionen,die ein Benut-zernunanseinerlokalenObjektformvornimmt,werdenuberdenDocument-Request-Broker zumserver-seitigenInterface-Objektubertragenunddannauf denSzenengraphdesOriginaldokumen-tesangewendet.Dies ist in Abbildung 5.5 durcheinenPfeil zwischenObjektreprasentationundInterface-Objektverdeutlicht.

Am Beginn einer Visualisierunsgsitzung stehtdem Benutzerlediglich eine Objektreprasen-tation desserver-seitigenGesamtdokumentesals Bildobjekt zur Verfugung.Durch Navigations-und Selektionsbefehlekanner sich in der Szenebewegenbzw. neueObjektreprasentationen an-fordern.DieseBenutzeraktionenwerdenstetsuberdie VermittlungsschichtzumServer-Dokumentubertragen.DasBasis-Interface-Objektder Gesamtszenestellt Methodenfur die Navigation undSelektion von Objekten zur Verfugung. Der Entwurf diesesAnsatzesmit Hilfe des objekt-orientiertenDokumentmodellseiner szenengraph-basierten Anwendungsschicht(OpenInventor)und einer Middleware-Schicht(CORBA) wird in Kapitel 6 im Detail beschrieben.Die zentraleBedeutungdesAnsatzesfur dieGesamtarchitekturseijedochschonhierbetont.


5.6 Managementvon Sicherheitsinformationen: Ein IPR-Filter

Um den Anforderungendurch Sicherheitsaspektein verteiltenUmgebungengerechtzu werden,mußdasKonzeptderSkalierbarenSzenenMoglichkeitenzur Integration,ExtraktionundEvalua-tion von sicherheitsrelevantenInformationenbieten.Hier soll esdarumgehen,die MoglichkeitenzumManagementvongeschutztenDokumentenunddenentsprechendenSicherheitsinformationenim KonzeptderSkalierbarenSzenenzuerlautern.AnhanddesAblaufsderrelevantenProzessebeimArbeitenmit geschutzten3D Dokumenteninnnerhalbder Software-ArchitekturSCA3D soll dasintegrierteSicherheitsmanagementverdeutlichtwerden.In Abbildung 5.6 ist dieserAblauf beimZugriff undbeiderSelektioneines3D DokumentesdurcheinenBenutzerdargestellt.

Abbildung5.6:Sicherheitsmanagementim KonzeptderSkalierbarenSzenen.

In Abschnitt2.4sindalsdierelevantenSchritteeinesumfassendenSicherheitsmanagementsdieAuthentifizierung,dieRechteverhandlung,dieTransformationvonObjekten(z.B.durchIntegrationvonIPR-Daten)unddieVerschlusselungbeiderUbertragungerkanntworden.An dieserStellewirdnunaufdieUmsetzungdererstendreiSchritte,namlichAuthentifizierung,RechteverhandlungundObjekttransformation,im Konzeptder SkalierbarenSzeneneingegangen.Der letzte Schritt, dieVeschlusselung,soll hiernichtweiterbeschriebenwerden,daernicht integralerTeil desKonzeptesist und durchVerwendungvon bekanntenVerschlusselungstechniken eingefugt werdenkann.Im


folgendenwerdendiegenanntenSchrittenaherausgefuhrt.Die in derAbbildungzentralenProzesseundDatenwerdenin derAuflistunganentsprechenderStellehervorgehoben:� Authentifizierung: Die Authentifizierung einesBenutzersgeschiehtbeim Anmeldenam

System-ServerundfuhrtzueinerEinordnungdesBenutzersin eineKategorie,wie Gast, ein-getragenesMitglied oderAdministrator. JederKategorie entsprichtein Rechtezustand,derin FormeinerSignaturandenBenutzerzuruckgesendetwird. JedeClient-Anwendungerhaltbeim AnmeldenaußerdemeineeindeutigeKennung,die mit der Signaturubertragenwird.Mitglieder und Administratorenbesitzenvor der AnmeldungbereitseineSignatur, die siedurcheinevorhergehendeOperationerhaltenhaben.DurchAbgleichdieserSignaturmit deram Server fur diesenBenutzergespeichertenSignaturwird eineAuthentifizierunggewahr-leistet.GastbenutzererhaltenminimaleRechteundeineSignatur, dieamEndeeinerSitzungverfallt.� Rechteverhandlung: Nachder erfolgreichenAnmeldungwird vom Benutzerein DokumentauseinerDatenbankin denSystem-Server durchRetrieval geladen.Gleichzeitigwerdensi-cherheitsrelevanteInformationen,wie z.B. DatenuberCopyright, ebenfalls auseinerDaten-bankin dasinterneDokumentmodelleingefugt, dasim Fall von 3D DokumentendemSze-nengraphentspricht.Im hierbeschriebenKonzeptwird dieseIPR-Inf ormation in FormvonAttributknotenin dieUntergruppenderbetreffendenInhaltsobjekteeingefugt.Bei einemZu-griff auf einzelneInhaltsobjektedesDokumentesdurchSelektionwird ein Interface-Objekterzeugt,dasdiezugehorigenIPR-Datenin Zustandsfeldernenthalt. Mit Hilfe dergleichzeitigmit derBenutzeraktiongesendetenRechtesignaturwird nundie Methodenschnittstelle desInterface-Objektesandie aktuelleRechtesituationangepasst.DiesgeschiehtdurchOffnungbzw. SperrungderbenotigtenAblaufeim Interface-Objekt,wobeidie in derSignaturenthal-tenenLoI-Datenverwendetwerden.WenneinBenutzerzusatzlicheRechteerwirbt,wird dieMethodenschnittstelle entsprechenderweitert.DieseAnpassungder MethodenschnittstelledesInterface-ObjektesentsprichtderIPR-Filter-Funktionalitat in Abbildung5.6.� Objekttransformation: SobaldeinBenutzerein3D Objektselektierthat,wird eineObjektr e-pr asentationin seineClient-Szeneeingefugt.DiesgeschiehtdurchdieErzeugungeinerdenRechtenentsprechendenObjektformbei derLevel-of-Information-Transformation. DieseObjektreprasentationwird durchgeeigneteMethodendesInterface-ObjektesausdenOrigi-naldatengeneriert,z.B.wird auseinemparametrisiertenOberflachenobjekteinepolygonales3D Netzerzeugt.Anschließendwird in dieseObjektreprasentationeineKopiederIPR-Datenintegriert (IPR Integration), indemeineverschlusselteSignaturdaranangehangtodereindi-gitalesWasserzeichendarineingebettetwird. In dieserForm wird eineKopiederoriginalenObjektdatenzumClient-Rechnerubertragen.

Bei jederweiterenInteraktionmit einemInterface-Objektwird dieRechtesignaturmit denIPR-DatendesDokumentesverglichen,um die aktuelleRechtesituationfestzustellen.Nur wenneineAktion erlaubtist, wird sievom Systemauchausgefuhrt.DurchdiesesKonzeptderRechteverwal-tungwird esmoglich,mit geschutzten3D Dokumentenin offenenInformationsraumenflexibel zuarbeiten.


5.7 DasKooperationsmodellder Skalierbaren Szenen

DasKonzeptderSkalierbarenSzenensoll dieKooperationzwischenmehrerenBenutzernin offenenInformationsraumenunterstutzen.Zu diesemZweck wird ein Kooperationsmodellin dasSystemintegriert,dasim folgendenvorgestelltwird.

Eine Software-Architektur, die dasKonzeptder SkalierbarenSzenenumsetzt,stellt mit je-derServer-Anwendungundmit jederClient-AnwendungeinenMethodenkern zur Verfugung,derzur Navigation in und zur Interaktionmit demGesamtdokumentdient.DieserKern von Metho-denist direkt mit der server-seitigenund client-seitigenSzeneverbundenund wird als Basisfurdie InteraktionuberdenDocument-Request-Broker verwendet.Die MethodenselbstsindTeil derDokumentkontroll-Objekte ausAbbildung5.5undwerdenuberRPCsmit Hilfe derunterliegendenMiddleware-Schichtaufgerufen.In Abbildung5.7 sindein Server undzwei Client-Anwendungenzusammenmit ihrem Methodenkern dargestellt.DasSymboldesKreisesmit einemeingeschrie-benenKreuzstellt dar, daßdieseMethodeubereinenRPCin derverteiltenUmgebungaufgerufenwerdenkann.Die NamenderObjektreferenzensindhier wegenderNahezumCORBA-Standardin derenglischenSprachebenannt.Die wichtigstenMethodendesKernswerdenim folgendenbe-schrieben:

Abbildung5.7:DasKooperationsmodellderSkalierbarenSzenenmit demMethodenkern.

� UpdateCamera: Mit dieserMethodewerdenKameraparametereinesTeilnehmersauf denSzenengrapheinesanderenTeilnehmersubertragen.Dadurchist einesynchronisierteNavi-gationzwischendenbeidenBenutzernmoglich.� Control Scene: Hiermit wird die Mengeder Methodenbezeichnet,die zur InteraktionaufObjektebenenotig sind.Im einzelnenwerdenTransformationen,wie z.B.VerschiebungoderSkalierung,und lokale Manipulationen,wie z.B. Anderungvon Eckpunktkoordinaten, mitHilfe dieserMethodenausgefuhrt. Konzeptionellsind dieseMethodenTeil der Methoden-schnittstelleder Interface-Objekteund werdendort angegeben.Als AusgangsbasiswerdenMethodenzurSelektionvonObjektenbereitgestellt.� ConstructSub-Scene: DieseMethodedientzumEinfugenvonTeildokumentenbzw. Objekt-


gruppenin einenbestehendenSzenengraph.Objektreprasentationen werdenauf dieseWeisein dieClient-Szeneeingefugt.� DeleteSub-Scene: Mit dieserMethodewerdenTeildokumentenbzw. Objektgruppenausei-nemDokumententfernt.Dies ist unteranderemnotig, wennein Objekt als OriginalkopiezumClient ubertragenwird unddasOriginalausderServer-Szenegeloschtwird.

Da jederTeilnehmerim System,alsodie Server-Anwendungund alle Client-Anwendungen,diesenMethodenkern zumZugriff auf ihr lokalesGesamtdokumentbereitstellen,mussendie Ob-jektreferenzenderMiddleware-Schnittstellefur jedenTeilnehmerunterschiedlichbenanntwerden.Dieswird hierrealisiert,indemandieNamenderObjektreferenzenderClient-MethodendieClient-Kennung(ID ) angehangtwird und dieseNamendannim Systembekanntgemachtwerden.Diesist moglich,dajederClient-Anwendungbei derAnmeldungeineeindeutigeKennungzugewiesenwird. Die Referenznamenfur denMethodenkerndesServerssindnichtmit einerzusatzlichenKen-nungversehen,so daßsie von jederClient-Anwendungsofort aufgerufenwerdenkonnen.DurchdieseNamensvergabekannjedeClient-Anwendungvom Server individuell angesprochenwerden,sodaßdasSystemsehrflexibel im Hinblick aufverschiedeneKooperationsszenarienwird.

5.8 AdaptivesVerhaltendurch dynamischeKontrolledesLoI-Reglers

Beim Arbeiten mit komplexen Dokumentenin verteilten Umgebungenist es wichtig, daß diezugrundeliegendeSoftware-ArchitekturMoglichkeiten zur Anpassungder Belastungvon Client-Ressourcenund desNetzwerkesbietet.In diesemAbschnittwird beschrieben,welcheMechanis-mendasKonzeptder SkalierbarenSzenenund damit die Software-ArchitekturSCA3D fur dieseAdaptionbietet.

Abbildung5.8:KlassifizierungvonClient-AnwendungenundZuordnungvonObjektreprasentatio-nenmit geeignetemLevel-of-Information.


Die grundlegendeIdeeist es,die Informationsmenge,die ubersNetztransportiertwird undamClient verarbeitetwerdenmuß,mit Hilfe desLevel-of-Information-Schiebereglers zu kontrollie-ren.In Abbildung5.8ist eineKlassifizierungvonClient-AnwendungenbezuglichderLeistungundAnbindungdergenutztenRechnergezeigt.DasSpektrumreichtvon mobilenEndgeraten(MobilerPDA), uberleistungsschwacheGeratemit guterAnbindung(PDA im LAN), uberleistungsstarkeRechnermit schlechterAnbindung(PC uber Modem)bis hin zu leistungsstarken RechnernmitsehrguterAnbindung(PC im LAN). JenachLeistungund Anbindungwird dasVerhaltnis zwi-schenlokalerundRemote-Visualisierungslastangepaßt.DiesgeschiehtdurchAuswahlundVertei-lung geeigneterObjektreprasentationen, die mit denSymbolenausAbschnitt5.4 ebenfalls in derAbbildunggezeigtsind.Die PositiondesLoI-Schieberegler sorgt dafur, daßjeweils die Objektre-prasentationenandieBenutzerverteiltwerden,diedenRandbedingungenambestenentsprechen.

Abbildung5.9: DynamischeKontrollederSchiebereglerpositionen in einerverteiltenMehrbenut-zerumgebung.

In Abbildung 5.9 ist ein Systemmit einem Informations-Server und zwei angebundenenClient-Rechnerngezeigt.Die Benutzerarbeitengemeinsammit einem3D Dokument,dasin denAnwendungs-Server geladenist. Die verfugbareBandbreiteund die lokaleCPU-Lastkonnenva-riieren, da sich die Gesamtnetzlastverandernkannbzw. zusatzlicheProzesseauf einerCPU ab-laufen konnen.JedeClient-Anwendungstellt einenLoI-Schieberegler zur Verfugung,mit demdie Reprasentationund Auflosungdeszu selektierendenObjektesbeeinflusstwerdenkann.AmClient wird die aktuelleLast laufendausgewertet,indemdie lokaleBildwiederholratederClient-AnwendungunterfestgelegtenBedingungengemessenwird. Die GuteeinesClient-Rechnerswirdbestimmt,indemregelmaßigdasoptimaleVerhaltnisvon lokalerundRemote-Framerateunddes-


senAnderungbeivariierenderInformationsmengeamClientermitteltwird. Die Gutegibt Auskunftdaruber, wie großdie LeistungeinesClientenaktuell ist undwie sichdieseuntervariierendenBe-dingungenim Systemvorraussichtlichandernwird.

Die EinstellungdesLoI-Reglerswird einerseitsdurchdieRechtesituationzwischenServerundClient bestimmtund andererseitsdurchdie Gutewerte desClient-Rechners.Die Rechtesituationfuhrt dazu,daßBereichedesSchiebereglersganzgesperrtseinkonnen.Dies ist in Abbildung5.9durcheineroteSchraffierungdieserPositionendesLoI-Reglersverdeutlicht.DurchAuswertungderGutewertewird dieoptimalePositiondesLoI-ReglerseinerClient-Anwendungfur dienachstenIn-teraktionsschrittefestgelegt. In Abbildung5.9hatdieunterederbeidenClient-AnwendungeneinenhohenGutewert und eineaktuell niedrigeLast. Daherstehtder LoI-Regler auf der Position,dieeineUbertragungvon moglichstviel geometrischerInformationerlaubt.Die Positionenoberhalbsinddurchdie Rechtesituationgesperrt.Der andereBenutzerarbeitetmit einemRechner, dereinegeringeGuteundbereitseinehoheLastaufweist.

5.8.1 Leistungsmessungund Regelgroßen

Meßgroßenim Gesamtsystemsinddie lokaleFramerate(LFR) unddie Remote-Framerate(RFR),die alsKehrwertderVerzogerungszeitzwischeneinerClient-Aktion unddesvisuellenFeedbacksvomServerermitteltwird. Die lokalenVerzogerungwird alsannaherndgleichzumKehrwertderlo-kalenFramerateangenommen.WeitereMeßgroßensinddieaktuelleInformationsmengeamServer³µ´9¶

(DocumentSize) undamClient³�´?·

, ausgedrucktdurchdieAnzahldergerendertenDreieckeeinerSzene.WeiterhinwerdendieinsgesamtvomServerausgegebeneDatenrate

³¹¸/¶(DataFlow)

unddieamClienteingeleseneDatenrate³º¸a·

fortlaufendbestimmt.

Abbildung5.10:Regel-undMeßgroßenin derSCA3DArchitektur.


� LokaleFramerate: Die lokaleFramerateLFRgibt dieBildwiederholratederVisualisierungs-anwendungdesBenutzersan.Die LeistungdesClient-Rechnerswird alsdirekt proportionalzur lokalenFramerateangesehenund ist naherungsweisegleichdemKehrwertder lokalenVerzogerung.Diesist in Formel5.1angegeben.

��¸ �¼»� Q9½§�¿¾ �<� (5.1)� Remote-Framerate: In die Remote-FramerateRFRgehtnicht nur die Server-FramerateSFRmit ein,sondernsiewird auchvon derUbertragungsverzogerung unddamitvon derNetzan-bindungbeeinflußt,dasieausdemKehrwertderGesamtverzogerungszeitdesvisuellenFeed-backsvom Server berechnetwird. DieseGesamtverzogerungszeitsetztsichausderZeit zurErzeugungeinesaktuellenBildesdesverandertenModells Q?À!�� , derZeit zurHinubertra-gungderBenutzeraktionundRuckubertragungderBilddaten Q9Á�� undschließlichderZeitzusammen,die benotigt wird, um dasBild als Textur am Client anzuzeigenQ!Âo�� kÃ=Ä � . Diesist in Formel 5.2 wiedergegeben,in der die Remote-Framerateals Kehrwertder Gesamt-verzogerungszeitangegebenist. Die lokaleRate,mit der Texturenvon der lokalenVisuali-sierungsanwendungangezeigtwerden,wird als(Texture-Mapping-Rate: TMR) bezeichnet.

� ¸ �Å»� Q9À!�� ¿� �Æ58Q9Á�� 5`QoÂ!�� kÃ=Ä � (5.2)

Die Remote-Frameratewird im Gesamtsystemgesteuert,indemdie Texture-Mapping-Ratevariiertunddieserver-seitigeBilderzeugungsrateautomatischdaranangepaßtwird. Die Mes-sungderGesamtverzogerungszeitgeschieht,indembeimAusloseneinerBenutzeraktioneineKennungzusammenmit einerStartzeitamClienterzeugtundmit denAktionsdatenzumSer-ver gesendetwird. Dort wird, nachdemdie Aktion auf dasModell ubertragenwurde,in dasnachstegenerierteBild dieAktionskennungunddieKennungderClient-Anwendungin einenfestenPixelbereichbinar eingebracht.Am Client wird jeweils dieserbekanntePixelbereichdaraufuntersucht,obdieaktuelleAktionskennungdesClientsdorteingebrachtwurde.Wenndieszutrifft, wird eineEndzeitermitteltunddieGesamtzeitderAktion ausgewertet.� Informationsmenge amServerundClient: Bei derVisualisierungwird sowohl amServer, alsauchamClient die aktuelleGroßedes3D Dokumentes

³µ´9¶bzw.

³�´9·laufendbestimmt.

SiewerdenausderAnzahlderzuberechnendenDreiecke ermittelt.� DatenrateamServerundClient : VomServerwerdensowohl Bilddaten,alsauchObjektdatenaufdasNetzwerkgeschickt,dieentwederuberSocket-Verbindungen(Bilddaten)odermittelsdesCORBA-interneDatenprotokolls (Objektdaten)zum Client ubertragenwerden.DurchProtokollierung der Datenmengepro Zeiteinheitwerdendie Gesamtdatenratenvon ServerundClient

³º¸a¶bzw.

³º¸a·gemessen.SokonnenindirektAussagenuberdenDatenflußund

uberdieAnbindunggetroffen werden.

In einemSystem,dasdasKonzeptder SkalierbarenSzenenumsetzt,existierenvariablePa-rameter, die alsRegelgroßenbezeichnetwerden.Die entscheidendenRegelgroßenin der SCA3DArchitektursindeinerseitsderLevel-of-Information-Parameter, derdenBetragdermit einemOb-jekt ubertragenenInformationregelt, und andererseitsdie Texture-Mapping-Rate,die angibt,wie


oft die Textur auf derProjektionsflacheamClient aktualisiertwird. In Abbildung5.10ist ein sol-chesSystemmit denbeidenRegelgroßenunddenobenbeschriebenenMeßgroßengezeigt.Zusatz-lich wird die server-seitigeFramerateSFRals Regelgroßebetrachtet,die jedochandie KontrollederTexture-Mapping-RateamClientgekoppeltist.DurchBeinflussungderclient-seitigenTexture-Mapping-RatekanndaherdievomServergelieferteBilddatenmengegesteuertwerden.Gleichzeitigwird davon auchdie lokaleFrameratebeeinflußt.EshandeltsichhierbeiumeinenRegelkreiszwi-schenClient und Server, der so eingestelltwird, daßfur einenBenutzerdasoptimaleVerhaltniszwischenlokalerundRemote-Framerategefundenwird.

Die gemessenenWertewerdenlokal verarbeitetoderuberdieMiddleware-Schnittstelleim Sy-stembekanntgemacht.Die AuwertungderMeßwertegeschiehtlaufendunddie Resultatewerdenin Form einerClient-Gute ausgedruckt, der die im folgendenbeschriebenePerformanzmetrikzu-grundeliegt.

5.8.2 Festlegungeiner Metrik zur Leistungsmessung

Die BestimmungdesoptimalenVerhaltnisseszwischenlokaler und Remote-Frameratebei einergegebenenSzenengroßegeschiehtdurcheineschrittweiseErhohungderTexture-Mapping-RatevoneinemminimalenWert bis zu ihren maximalenWert, auf den dasSystemnoch reagiert.DieserAuswertungsschrittwird in regelmaßigenAbstandenwiederholt.AusdenentstehendenMeßreihen,die denVerlaufderlokalenundderRemote-Frameratein Abhangigkeit von derTexture-Mapping-Ratewiedergibt, kanndasoptimaleVerhaltnisderlokalenundRemote-Frameratebestimmtwerden.Diesist in Abbildung5.11gezeigt.DeroptimalePunktist hierdurchdiegroßteSteigungderKurvedefiniert.

Abbildung5.11:BestimmungderoptimalenFrameratendesClientsunddesServers.

Auf der linkenSeitevon Abbildung5.11ist derVerlaufderLFR-RFR-Kurve gezeigt,dermitdemWert derTexture-Mapping-Rateparametrisiertist. Fur ein symbolisches3D Objektist außer-demdaslokaleundentferntevisuelleFeedbackbeimVerschiebendesObjektesgezeigt.Die lokaleObjektreprasentationreagiertmit einerVerzogerung,die geringeralsdieRemote-VerzogerungdesOriginalobjektesist. Dadurchenstehtder Eindruck,als ob Server- und Client-Objektdurch einGummibandverbundensind. Durch die Einstellungder Client-Anwendungam Punkt ' ��Ç�� wirddemGummibandeineoptimaleElastizitat gegeben,damitder Benutzersowohl lokal bequemar-


beitenkann,als auchein sofortigesFeedbackvom Server bekommt. Auf der rechtenSeitevonAbbildung5.11ist die AuswertungderSteigungderLFR-RFR-Kurveaufgetragen,wobeidie ver-schiedenenKurven zu einerunterschiedlichenGeometriebelastungdesClient-Rechnersgehoren.Fur eineanwachsendenSzenengroßeamClientverschiebtsichdieseKurveundverandertteilweiseihre Form. Die Kurve wurdendurchInterpolationder Meßwertemit Hilfe desAuswertungspro-grammsGnuploterzeugt.

Abbildung5.12:ErmittlungderLeistungunddesVerhaltenseinesClient-RechnersbeivariierenderGeometriebelastungundVerbindungsbandbreite.

In Abbildung 5.12 ist das Verhaltenzweier Client-Anwendungenbei der VeranderungderRandbedingungen,d.h. der lokalen Geometrielastund der Anbindungsbandbreite, im LFR-RFR-Diagrammgezeigt.Die Lage einesoptimalenPunktes' ��Ç�� im LFR-RFR-Diagrammwirddurch seineEntfernungvom Ursprung

� � ��¸ �G�� ¸ �r$È�ÊÉ ��¸ � + 57� ¸ � + und vom Winkel�T� ��¸ �G�� ¸ �r$ zwischender RFR-Achseund der Achse,die durch den Ursprungsund ' ��Ç��verlauft, angegeben.Die Lange

�ist ein Maß fur die LeistungdesRechnersund der Winkel �

erlaubtAngabendaruberzu machen,ob ein Rechnerbesserfur die RemoteVisualisierungoderdie lokale Visualisierunggeeignetist. Bei der Belastungvon Client mit einergroßerenAnzahlvon DreieckenverschiebtsichdasVerhaltnisvon LFR undRFRin RichtungderRFR-Achse,wiein Abbildung5.12dargestellt.Die lokaleFrameratenimmt ab,wahrenddie Remote-Framerateimwesentlichengleichbleibt.Die anfanglicheLeistung

� (��d¬§Ë\q sinktaufeinLeistung »� (T�p«§ËÌ¯ beieinerZunahmederDreiecksanzahlvon ��t�t� auf ¬E�t�t�t� Dreiecke in derClient-Szene.

Im Fall von Client q , dermit� + �� EË� eineschwachereLeistungalsClient aufweist,wurde

dieverfugbareBandbreitevon ��t�têÍPÎE� schrittweiseauf �ÏË\¬EêÍmÎE� verringert.DasVerhaltenderClient-Anwendungist in Abbildung5.12ebenfalls gezeigt.Die lokale Frameratesteigt,wahrenddie Remote-Frameratesinkt, da die Client-AnwendungwenigerBilddatenerhalt und dahermehrLeistungfur dieVerarbeitungderlokalenGeometrieaufbringenkann.DiesesVerhaltenwird durchdieautomatischeAnpassungderClient-AnwendungnachjederPerformanzauswertungerreicht.

Die Gleichungenzur Bestimmungder Leistung�

, desWinkels � und der Große¸

, die die


Anderungder Leistungfur zwei aufeinanderfolgende Auswertungsschrittewiderspiegelt, sind imfolgendenangegeben:

� � ��¸ �G�� ¸ �r$Ð� Ñ ��¸ � +��Ç�� 5>� ¸ � +��Ç�� (5.3)

(5.4)Ò�Ó � � � ��¸ � ��Ç�� ¸ � ��Ç��(5.5)¸ � Ô ��¸ �ÕR�Ôm� ¸ �

Um dasVerhaltenzweierRechnervergleichenzukonnen,sollteein Maßfur die AnderungderLeistungbeieinerfestgelegtenZunahmederBelastunggefundenwerden,z.B.beiderzusatzlichenBelastungbeiderClient-Anwendungendurchdie gleicheMengean Dreiecken. DieseMaß wirdhieralsGutebezeichnetundfolgendermaßenbeschrieben.Die Gute O einesClient-RechnerswirddurchdiedreiobigenWertebestimmt,d.h. Od��OK� � �� ¸ $ . Die Werte Ô ��¸ � und Ôm� ¸ � gebendabeidie AnderungenderGroßenvon einemAuswertungsschrittzumnachstenan.Die Gutewertewerdennunfolgendermaßenausgedruckt, wobeiderIndex ¤¦�9¤ denAusgangswerteinerGroßevordererneutenPerformanzauswertungmeint.

Od� � �¸ � ��Ô ��¸ �r$D��Ôm� ¸ �r$ Ñ � � ��¸ � +�¢� 5 �� ¸ � +�¢� (5.6)

Abbildung5.13:VerlaufderGewichtungsfaktoren�=� und � � .

Um den Einfluß desWinkel � zu berucksichtigen,sind Gewichtungsfaktorenin Gleichung5.6 fur die Guteeingefugt worden,die die jeweiligenAnteile von LFR undRFRamGesamtwertverstarkenbzw. schwachen.DieseGewichtungsoll ausdrucken,daßClient-Anwendungen,die so-wohlhohelokaleFrameratenalsauchhoheRemote-Frameratenaufweisen,starkerzubewertensind


alssolche,die lediglicheinehohelokaleLeistungaufbringen.Eswird angenommen,daßdieWin-kelwertezwischen�¬ � und �E� � variierenkonnen,dafur Winkel unter ¯�¬ � dieRemote-Verzogerungkleineralsdie lokaleVerzogerungseinmusste.DieserFall kannaberpraktischnicht vorkommen,dadieTexture-Mapping-RatenichtgroßeralsdielokaleFrameratewerdenkann.Bei einemWinkel�Ö�×¯�¬ � sollenbeideAnteile gleich starkgewichtet werden,wahrendmit ansteigendemWinkelgegen �H�Ö�E� � derLFR-Anteil schwacherundderRFR-Anteilstarker bewertetwerdensoll. EinemoglicheWahl derGewichtungsfaktoren� � und �=� ist in denfolgendenGleichungen5.7gezeigt.Der Verlauf der beidenFaktorenzwischen�d�Ø¯�¬ � und �I�Ø�E� � ist in Abbildung5.13gezeigt.Bei �I�Ù¯�¬ � habenbeideFaktorendenWert EËÚ� , wahrendfur �I�Û�E� � die FaktorenWertevon�=� �Ü EË\¬ und � � �c�ÏË\¬ annehmen.�� «q f q ��¤¦� + ��qE�/$ ¥!�?: � � � q 5 q ��¤¦� + ��qE�/$ (5.7)

Die Performanzmetrik'N^ zumVergleichvon zwei Client-Rechnernwird danndurchdie eu-klidischeDistanzderGutewertefestgelegt:

'N^ � Ñ O + · �\�� + f O + · �Ú�k�� ( (5.8)

In den folgendenKapiteln wird die Einordnungvon Client-Rechernin Leistungsklassenmitdenhier beschriebenenGroßenzurLeistungsbewertungbeschrieben.Dazuwird in ersterLinie derLeistungswert

�verwendet.Die KontrolledesLoI-Reglersmit Hilfe der Performanzmetrikist in

Kapitel8 dargestellt.

5.9 Zusammenfassung

In diesemKapitel wurde dasKonzeptder SkalierbarenSzenenin einer Gesamtubersichtvorg-stellt und mit Ansatzenausder Literatur verglichen.Daraufwurdendie wichtigstenKomponen-ten desKonzeptesvorgestelltund nacheinanderim Detail beschrieben.Der Ansatzder TrennungeinesNavigations-undInteraktionsraumes,diedurcheineKombinationvon lokalemundRemote-Renderingfur einenBenutzerzuganglichgemachtwerden,und der Level-of-InformationAnsatzzum variablenUmgangmit allen Objektreprasentationen der Visualisierungs-Pipelinein einemverteiltenSystemsind als Kern der Arbeit hervorgehobenwurden.Ein kooperatives Modell zurMehrbenutzer-Visualisierung, ein KonzeptzurRechteverwaltungim SystemundeinePerformanz-metrik zur Klassifizierungvon Client-RechnernwurdendiskutiertundLosungenfur die Software-Architektur SCA3D aufgezeigt.In den folgendenKapiteln wird nun der Entwurf und die Um-setzungdieserSoftware-ArchitekturnachdemKonzeptder SkalierbarenSzenenbeschrieben.Imweiterenwird dannder Einsatzvon SCA3D zur adaptiven 3D Visualisierungvon geschutzen3DDokumentenin DigitalenBibliothekenunddaskooperative Modell untersucht.

Kapitel 6

Entwurf der verteiltenSoftware-Architektur

In diesemKapitel wird der software-technischeEntwurf desKonzeptesausdemvorhergehendenKapitel beschrieben.Als ResultatedesKapitelswerdenein Analysemodellundein DesignmodellderSoftware-ArchitekturSCA3D,diedasArbeitenmit skalierbarenSzenenermoglicht,angegeben.AnhandderKomponentenundTeilsystemedesEntwurfswird derAufbauderSoftware-Architekturvorgestellt und die KommunikationinnerhalbdesSystemserlautert.Mit Hilfe von Diagramm-darstellungenausdemUmfangderModellierungsspracheUML werdenverschiedeneSichtenderSoftware-Architekturbeschrieben.

6.1 Einf uhrung: Der Entwicklungsprozeß

DerprofessionelleEntwurfvonSoftware-Systemensiehtin derRegelvier Phasenvor, namlichdieAnalysephase,die Designphase,die Implementierungsphaseund zuletztdie Integrationsphase.InderAnalysephasewerdendie AnforderungenandasSystemin einerUbersichtfestgestelltund inFormeinesAnalysemodellsbeschrieben.In derDesignphasewird dieVoraussetzungeineridealen,nichtweiterbeschriebeneSystemumgebungaufgegebenundein Designmodellangefertigt,dasdieRandbedingungenderRechnerumgebungberucksichtigt.In derImplementierungsphasewerdendieBestandteiledesSystemsangefertigt,z.B.durchProgrammierungeinesobjekt-orientiertenSystemsin einergangigenSprache.In derIntegrationsphasewird dasSystemnachmoglichstumfangreichenTestsin dasGesamtsystemeingebracht.DieserSchritterfolgtnur fur großeSysteme,dieausvielengetrenntentworfenenTeilsystemenbestehen.

Bei einemiterativen bzw. spiralformigenEntwurfsprozeß(siehez.B. [Jac92]) werdennundievier Phasenvon neuemdurchlaufen,um sodasSystemimmerbesserandie tatsachlichenAnfor-derungenund Randbedingungenanzupassen.In jedemDurchlaufder Spiraleentstehteinefunk-tionsfahigesTeilsystem.In Abbildung 6.1 ist der beschriebeneEntwicklungsprozeßdargestellt.Zusatzlichzu denglobalenIterationsschrittensolltennachjederImplemetierungsphaseauchTest-schrittedurchgefuhrt werdenunddie Ergebnissedirekt zur VerbesserungdesaktuelleSystemsbe-nutzt werden.Bei der Entwicklungder Software-ArchitekturSCA3D wurde dieseArbeitsweiseverfolgt.Der IntegrationsphasekamdabeiwenigBedeutungzu,daSCA3Dnicht alsTeilsystemineingroßeresSystemeingefugt werdensollte.

Zur BeschreibungdereinzelnenPhasenwird dieSpracheUML (siehez.B. [Alh98]) verwendet,die auseinerZusammenfassungderwichtigstenobjekt-orientierten Entwurfsmethodenentstanden

93

KAPITEL 6. ENTWURFDERVERTEILTEN SOFTWARE-ARCHITEKTUR 94

Abbildung6.1: Iterativer Entwurfsprozeßfur Software-Systeme.

ist und heuteeinenweitverbreitetenStandarddarstellt.Die Notationvon UML umfaßtDiagram-me fur die Darstellungder verschiedenenAnsichtenauf dasSoftware-System.Ein Modell stelltwichtige Aspekteder Realitat dar, beschreibtabernicht alle EinzelheiteneinesrealenSystems.Die Verwendungvon DiagrammenbieteneineMoglichkeit wichtigeAspektedesSystemsheraus-zuarbeitenund damit dessenKomplexitat fur denEntwickler zu reduzieren.In diesemSinn sinddie Entwicklungsdiagrammeals Ausschnittsansichten einesGesamtsystemszu sehen.FolgendeDiagrammartenwerdenvon UML unterstutzt: Use-Case-Diagramme,Klassendiagramme,Interak-tiondiagramme,Package-Diagramme,Zustandsdiagramme,Aktivitatsdiagrammeund Implemen-tierungsdiagramme.UML bietetzur ErstellungdergenanntenDiagrammeeinefestgelegteMengevon Beschreibungselementen. Da nichtalle Diagrammtypenhier verwendetwerden,sollennurdietatsachlichbenotigtenbeschriebenwerden.� Use-Case-Diagramme: Use-Case-Diagrammewerdenin allenvier PhasenderEntwicklung

angewendet.Use-Caseswurdenzuerstvon Jacobson[Jac92] eingefuhrt undbeschreibendasZusammenwirken von Aktoren, d.h. PersonenoderanderenSystemen,mit einemSystem.Personenwerdennachihrem Rollenverhaltenunterschieden,also z.B. Kundeund Admi-nistrator. Die Use-Casesselbstsind typischeHandlungen,die ein Aktor an einemSystemausfuhrt, undwerdenalsEllipsenin demDiagrammdargestellt.DurchLinien zwischendenUse-CasesunddenAktorenwerdenVerbindungenhergestellt,z.B.usesoderextends.� Klassendiagramme: Klassendiagrammewerdenvorallemin denDesign-und Implementie-rungsphasenbenutzt.Dabei werdendie im SystemvorkommendenKlassenbeschrieben,die z.B. durchVerwendungvon CRC-Karten(Class, Responsibility, Collaboration) ermit-telt wurden.UML unterscheidetKlassenund Objektein denDiagrammennicht. Im Klas-sendiagrammwerdendie Klassendurchein Symbolvertreten,dasdenNamen,die enthalte-nenAttribute und die Methodenenthalt. Die SymboledereinzelnenKlassenwerdendurchVerbindungenin Beziehungzueinandergesetzt.Die wichtigstenBeziehungensindAssoziati-on (allgemeineBeziehung),Aggregation(Ist-Teil-von-Beziehung), Komposition(Enthalten-sein-in-Beziehung)undVererbung(Ist-ein-Beziehung).� Interaktionsdiagramme: DieseDiagramme,diedenzeitlichenProgrammablaufalsAufrufse-quenzenangeben,werdenin allenvier PhasenderEntwicklungeingesetzt.EswerdenweiterSequenzdiagrammeundKollaborationsdiagrammeunterschieden.Bei denSequenzdiagram-menwerdendieKlassensymbolehorizontalaufgereihtundvon jederKlasseeinesenkrechte


Linie, die die Zeitachsedarstellt,nachunterngezeichnet.ZwischendiesenLinien werdenAufrufe zwischenKlassendurchPfeiledargestellt.DasKollaborationsdiagramm unterschei-detsichnurdurchdieDarstellung,diekeinesenkrechtenZeitachsenverwendet,sonderndenAblauf durchSequenzenvonKlassendarstellt[Wah98].

6.2 Anforderungsanalyse:Komponentenund ihreModellierung

In diesemAbschnittsoll eineAnalysederAnforderungenandie Software-ArchitekturSCA3Der-stellt werden.Dazuwird zuerstein Use-Case-Diagrammangefertigt,um einenUberblickuberdieFunktionalitat desSystemszu erhalten.Dannwerdendie Klassenbzw. Objekteim ProblemraumdesKonzeptesidentifiziert und in Beziehungzueinandergesetzt. Zusammenmit dem Use-Case-Diagrammwird darausdasAnalysemodellerzeugt.HinzukommenkonnennochSichtenauf dasSystem,z.B. in Form von prototypischenBenutzerschnittstellen. In der folgendenAuflistungsindnocheinmaldiewichtigstenAnforderungenaneinSystemgenannt,dasdemKonzeptderSkalierba-renSzenenentspricht.Die Anforderungsanalyseist in dreiHauptbereicheeingeteilt,namlichdigita-le 3D Dokumente,offenenInformationsraumeundDigital-Library-Systeme(DL-System),umeineVorstrukturierungder Anforderungenan dasSystemszu erlauben.Die SCA3D-Architekturwirdalsein solchesDL-Systementworfen.Die allgemeineAnforderungenandie Software-ArchitekturSCA3Dsehenwie folgt aus.

Anforderungenan digitale 3D Dokumente:� Aufbau:Struktur, InhaltundMetadaten� Dokumentschnittstellenfur: visuellesCut-and-Paste,Indizierung,Erweiterbarkeit, Sicher-heitsmanagement� Anpassbarkeit derKomplexitat: Level-of-Information-Ansatz

Anforderungenan offeneInformationsraume:� EinheitlicheBedingungenfur dasArbeitenmit digitalenObjekten:Navigations-undInterak-tionsraume� SchnittstellenzuanderenoffenenInformationsraumen� MoglichkeitenzumSicherheitsmanagement

Anforderungenan DL-Systeme:� ErfullungderCharakteristikenvonoffenenInformationsraumen� Unterstutzungvondigitalen3D Dokumenten:objekt-orientiertes,internesDokumentmodell,KommunikationzurUnterstutzungdesLevel-of-Information-Ansatzes� MoglichkeitenzurErkundungbestehenderDL Dokumente(Retrieval, Darstellung,Interakti-on),zumGenerierenundHinzufugenneuerDokumente� Bewertungsmoglichkeit fur dieGute(LeistungundAnbindung)vonBenutzerrechnern� Kooperationsmoglichkeiten: Benutzerverwaltung,Synchronisation,Awareness


Abbildung6.2:ErweitertesUse-Case-Diagrammfur SCA3D.

Fur dasSCA3D-System,dasentsprechenddiesenAnforderungenentwickelt wurde,ist in Ab-bildung6.2einerweitertesUse-Case-Diagrammdargestellt.DerAnwenderist derHauptakteurdesSystems.Er bedienteineClient-Applikation,die ubereineSystemschnittstellemittelseinesNetz-werkesmit demSerververbundenist.DerServerwiederumist mit Datenbankenverbunden,diediedigitalenDokumenteund die dazugehorigenSicherheitsinformationen enthalten.Die wichtigstenAktionensind in diesemSzenariodurchovaleSymbolereprasentiert.Die Aktionen,die zwischenClient undServer ablaufen,werdenmit Hilfe einesMiddleware-Interfacesubertragen.AußerdemwerdenDatenuberSocket-Verbindungen(Bilddaten-Interface)undHTTP-Verbindungen(WWW-Interface)ubertragen.

Dem Benutzerwird lokal ein 3DVis-GUI (Graphical User Interface) fur die interaktive 3DVisualisierungzurVerfugunggestelltundeinePanel-GUI,dasdieKontrollelemente,wie z.B.LoI-Schieberegler und Performance-Anzeige,enthalt. Weiterhinkonnendie Server-KomponentenderSoftware-Architekturuber eine WWW-Schnittstellekontrolliert werden,um z.B. den Server zustartenbzw. zu stoppenoderauf die Datenbankzuzugreifen.Die wichtigstenHandlungeneinesBenutzerssind in Abbildung 6.2 direkt mit dem Akteur verbunden:Anmelden,3D Dokument-Retrieval, interaktive 3D Visualisierung,Objektselektion,Objektmanipulationund PositionierungdesLoI-Schiebereglers.Die Handlungenim Zusammenhangmit derexternenDatenbanksind:3DDokument-Auswahl und3D Dokument-Laden.Die weiterenHandlungenin Abbildung6.2 laufeninternundzwischenClientundServer ab.

Um in der AnalysephaseeinenEindruckvon denBenutzerschnittstellen desSystemszu be-kommen,werdendieseals Sichtengraphischdargestellt.Es handeltsich bei diesenSichtenumGUI-PrototypenohnedahinterliegendeFunktionalitat. In Abbildung6.3 sinddie Benutzerschnitt-stellen3DVis-GUI undPanel-GUIgezeigt.Das3DVis-GUI dientalsSchnittstellezur interaktiven


Abbildung6.3:SichtderBenutzerschnittstellen 3DVis-GUI (links) undPanel-GUI(rechts).

Visualisierungder 3D Dokumente,wahrenddasPanel-GUIdie verschiedenenSchieberegler derClient-Applikation,Anzeigefelderfur lokale Framerate,Remote-Frameratenbzw. Gutewerteundein Auswahlfeld fur Methoden(z.B. getIPRInfooderRetrieval) bereitstellt.KontrollelementeimVisualisierungsfensterdes3DVis-GUI gebenInformationenuberdenaktuellenNavigationsmodusfur den Mehrbenutzerbetrieban (farbiges3D Symbol im linken unterenBereich)und uber dieTeilnehmer, die durchLogos im unterenrechtenBereichdargestelltwerden.NebendemLevel-of-Information-Regler ist hier auchein Regler zur Kontrolle der lokalen Texture-Mapping-Rateeingefugt,derzurEinstellungdesVerhaltnissesvon lokalerundRemote-Verzogerungdient.

6.3 Designmodell:Verteilter Entwurf fur dasKonzeptder skalierba-renSzenen

Nachdemdie Anforderungsanalyse abgeschlossenist, wird nundie Systemumgebung in denEnt-wurf miteinbezogen.Zu diesemZweck wird ein Designmodellerstellt,dasdie obenermitteltenKlassenund Subsystemenaherbeschreibtund auchdie Verteiltheit desSystemswiderspiegelt.Die Designphasebeginnt daher, sobalddie Randbedingungender Implementierungberucksich-tigt werden.Die Software-ArchitekturSCA3D ist eine Client-Server-Architektur und wird alsobjekt-orientiertesSystemumgesetzt.DerallgemeineAufbauenthalt einServer-System,einClient-SystemundeineMiddleware-SchnittstellezwischendiesenbeidenHauptkomponenten.DadasSy-stemin der spaterenImplementierungsphasemit der objekt-orientierten SpracheJava, der Midd-lewareCORBA undweitgehendplattformunabhangigrealisiertwerdensoll, werdenim folgendendieseRandbedingungenbeimDesignberucksichtigt.

Die wichtigstenBestandteiledes Gesamtsystemswerdennun mit Hilfe verschiedenerDia-grammenahererlautert.Zur Strukturierungder verschiedenenSichtweisenauf die Architektur,d.h. der verwendetenDiagramme,ist in Abbildung 6.4 dasPackage-Diagrammder SCA3D Ar-chitekturdargestellt.Package-Diagrammegebendie HauptkomponenteneinesSystemsundderen


Abbildung6.4:Package-DiagrammderSCA3DArchitektur.

Abhangigkeitenbei AnderungeinerKomponentean.Hier sinddie wichtigstenKomponentendieSCA3D Server-Applikation, die SCA3D Client-Applikation,dasControllApp-IDL-InterfaceunddasClient-Panel.Die Abhangigkeiten,diedurchunterbrocheneLinien gekennzeichnetsind,beste-henzwischender ControllApp-Komponenteund allen anderenKomponenten.AußerdembestehteinedirekteAbhangigkeit zwischenServer und Client durchdie Bildkommunikationsschicht, sodaßbei AnderungenanderBildubertragungin denmeistenFallenClient- undServer-Klassenan-gepaßtwerdenmussen.InnerhalbdesServer- undClient-PackagesindjeweilsweiterePackagesfur3D Visualisierung,Dokumentkontrolle und Bilddatenkommunikationeingetragen,die die Haupt-komponentenderjeweiligenAnwendungausmachen.

6.3.1 Die Visualisierungskomponenten

Die Komponentenzur3D Visualisierungbestehenauseinerserver-seitigenundeinerclient-seitigenVisualisierungsanwendung, diejeweilseineninteraktivenSzenengraphverwalten.ZumAufbaudie-serVisualisierungskomponenten wird dasOpenInventor-API verwendet.Nachdemein Basissze-nengraphaufgebautist, der durchEinlesenexterner3D Dokumentein entsprechendeSzenengra-phobjekteentsteht,wird dieserandie InstanzeinerOffscreen-Renderer-Klassebzw. einerViewer-Klasseubergeben.Im erstenFall werdenBilddatenin eineninternenBuffer abgelegt, dieweiterver-arbeitetwerdenkonnen,im zweitenFall werdenBilder direktaufdemBenutzerbildschirmausgege-ben.WeiterhinwerdenAktionendesBenutzersausgewertetundalsEingabeauf denSzenengraphangewendet.In Abbildung6.5sinddieseKomponentendargestellt.

Beide Visualisierungsanwendungen werdenverbunden,indem die Bilddaten,die am Servervom Offsreen-Rendererin denBildbuffer geschriebenwerden,amClient durchTexture-Mapping


Abbildung6.5:Komponentender3D Visualisierungsschicht.

in denlokalenSzenegraphintegriertwerden.Die SynchronisationderBenutzeraktionenvonClient-Anwendungund Server-Anwendungschließtden interaktiven Visualisierungskreis.Durch Aus-tauschvon 3D Objektenzwischenden Szenengraphenwird das interaktive Arbeiten mit demServer-Dokument ermoglicht. Der Entwurf des dazu verwendetenDocument-Request-Broker-Ansatzeswird im folgendenAbschnittbeschrieben.

6.3.2 Modellierung einesDocument-Request-Brokers

Der in Abschnitt5.5 vorgestellteAnsatzeinesDocument-Request-Brokers fur verteilte3D Doku-mentesoll nun im Detail beschriebenwerden.DieserAnsatznutzt denAufbau eines3D Doku-mentes,der eine interneAbbildung auf ein objekt-orientiertesDokumentmodell(OpenInventor-Szenengraph)erlaubt,ummit TeilgruppendesDokumenteszuarbeiten.

Abbildung6.6:SchematischerAufbaudesDocument-Request-Brokers.


In Abbildung6.6 ist derAufbaudesDocument-Request-Brokersschematischgezeigt.Das3DDokumentselbststellt dort die ubergeordneteGruppe O£� dar, die am Beginn einer Visualisie-rungssitzungdemBenutzerals visuellesInterfacedurchRemote-Renderingder GesamtszenezurVerfugunggestelltwird. DurchSelektioneinerBildschirmpositionkannnuneineUntergruppedesDokumentesOP in denZustandeinesaktiven Objektesgebrachtwerden.Dazuwird auf Server-SeiteeineObjekt-ReprasentationÝ£�m undeinInterface-Objekt�ÏÝm , dasalsVerbindungzwischendemOriginalobjektim Server-SzenengraphundderObjekt-Reprasentationdient,erzeugt.DieKlas-seder Interface-Objektein derSCA3D-Architekturist von derKlasse

´ � ´ s �!2�Þt2%0¿�¢Þ desverwen-detenVisualisierungs-APIabgeleitet,sodaßesalle MethodeneinesGruppenobjekteserbt.Die er-zeugteObjekt-Reprasentationwird dannzum Client ubertragenund in denlokalenSzenengrapheingefugt.DurchVerwendungeinesNamensschemas,dasdieIdentifizierungdesInterface-Objektesfur ein aktivesObjektunddessenBenutzerzulaßt,konnennunclient-seitigeMethodenaufrufeandasInterface-Objektweitergeleitetundauf dasOriginalobjektangewendetwerden.DieseMetho-denkonnenunteranderemdie folgendenOperationenauslosen,wie in Abbildung6.6dargestellt:� Fur das GesamtdokumentON� : ChangeCameraParameters(Navigation), ActivateObject,

ChangeGlobalParameters.� Fur TeilgruppenOP - Ou� : InteractObject(Manipulation),SelectObject,GetObjectRepresen-tation,GetIPRInfousw.

Um denAblauf beimAktiviereneinesObjektesundbeimAbsetzeneinesRemote-Document-Calls(RDC)zuerlautern,ist in Abbildung6.7einSequenzdiagrammdieserVorgangegezeigt.DieKlassen,die daranbeteiligtsind,sindim Sequenzdiagrammeingezeichnetundebensodie Metho-denaufrufezwischenihnen.Der zeitlicheAblauf beim AktiviereneinesObjektes,dasvorher imZustandeinesinaktivenServer-Objektsist undnunin denZustandeinesaktivenObjektesubergeht,wird durchdasSequenzdiagrammerlautert.DurchAuswahl einerBildschirmpositionim Viewer-Fenstermit derMethode�xs�©�s��0D�¦$ selektiertderBenutzereineTeilgruppedesServer-Dokumentes,fur dieamServer ein Interface-ObjektundamClienteineObjektreprasentationangelegt wird.

Abbildung 6.7: Sequenzdiagrammfur die Aktivierung einesObjektesund die ErzeugungeinesInterface-Objektes.


Zu diesemZweck wird auf Client-Seitenur die Remote-Rendering-Information der Server-Szeneverwendet.Auf Server-Seitewird dieSelektionsinformation,d.h.dieBildschirmpositionmitdenKameraparametern,dazuverwendet,dieSelektionsmethode�xs�©�s��0D�¦$ aufdasOriginaldokumentanzuwenden.Fur dasausgewahlteObjektwird diePfadinformationextrahiertundfur diesesObjektein Interface-Objektmit der Methode ��¢�n��0�ÞE¥o�<04�§ÝK�¦$ erzeugt.DiesesInterface-Objektwird demBenutzerzugeordnet,indemesin die zugehorige InstanzderKlasseL£©�¤�s=�90 � ¤��=04ßr©�s=à�s��90 mit derMethode2%:%:��ÏÝP�¦$ eingetragenwird. In einerListederInstanzenvon L£©�¤�s=�90 � ¤��=04ßr©�s=à�s��90 werdendie Benutzerinformationenverwaltet.Mittels derMethodew§s��ns=Þt2�0 sxÝN�P�¦$ desInterface-Objekteswird nuneinepassendeObjektreprasentationÝN� erzeugtundmit einemeindeutigenNamenver-knupft. DieseObjektreprasentationwird andenClient gesendetundmit derMethode�xs=0 ÝN�P�¦$ indie Liste der Objektreprasentationenund in die Client-Szeneintegriert. DasObjekt befindetsichnunim ZustandeinesaktivenObjektesundderBenutzerkannuberseineObjektreprasentationaufdasserver-seitigeObjekt zugreifen.Zum Aufruf einerMethodewird der Methodennameund dieParameterandasentfernteObjekt ubergebenunddort ausgefuhrt. DasdazuverwendeteNamens-schemaunddieentferntenMethodeaufrufe,hieralsRemote-Document-Callsbezeichnet,werdenindenfolgendenbeidenAbschnittenerlautert.

DasDRB-Namensschema

Um Objektreferenzenim Systembekanntzumachen,wird eineNamenschemaverwendet,dasdenStatusdesjeweiligen 3D Objektesund die KennnungendesInterface-Objektesund der Client-Anwendungenthalt. Inaktive Objekteauf Server-Seitewerdendurch eine Namengekennzeich-net, der mit

´ � beginnt. Inaktive Objekt auf Client-SeiteerhaltenNamen,die mit´ q anfangen.

Jedes3D Objekt im aktiven Zustanderhalt einen eindeutigenNamen,der nach dem Schema´ f � ³ f ËkËkË f � ³ � aufgebautist.DabeibedeutetderersteTeil´ , daßsichdasObjektim Zustand

einesaktiven Objektesbefindet.Die Namensteile� ³ � beziehensich auf die Client-Anwendung,die diesesObjektaktuell interaktiv bearbeitet,alsoz.B. � ³ t =á fur die Client-Anwendungmit derNummer t =á . Die zugehorigenInterface-ObjektewerdennachdemSchema�ÏÝuà f � ³ � benanntundenthalteneineReferenzaufdasoriginale3D Dokument.DerersteNamensteil�§Ý£à gibt dabeidieNummerdesInterface-Objektesin derListealler Interface-ObjektediesesBenutzersan.

Die eindeutigenNamenwerdenbeim Erzeugender Interface-Objekteals Metadatenmit demObjektverknupft undbei der UbertragungzumBenutzerdenObjektreprasentationen zugeordnet.Fur jedeClient-Anwendungwird am Server eineeigeneListe mit Referenzenauf die Interface-Objekt verwaltet. Beim Aufruf einer Methodewird uber eine client-seitigeListe der Objektre-prasentationdie passendeObjektreferenzamServer ermitteltunddie Methodefur desgefundenenObjektesausgefuhrt.

Remote-Document-Callsund SCA3D-Nachrichten

Das Prinzip der hier vorgestelltenRemote-Document-Callsist der Aufruf von MethodeneinesentferntenObjektesim Server-SzenengraphuberObjektreprasentationen in derClient-Szene.DieausfuhrbarenMethodensindeinerseitsdievondemVisualisierungs-APIbereitgestelltenundande-rerseitszusatzlicheMethodendievomangelegtenInterface-Objektangebotenwerden.BeispielefurdiezweiteKategoriesindz.B.die Methodenw§s=0 Ýr64z�s=��04�Ns4�AÞ@sx�xs=�90¿2%0�¤��x��¦$ (Level-of-Information)oder w§s�04��'r�£�@� b �.�¦$ (Sicherheitsmanagement).

ZumentferntenAufruf derentsprechendenMethodewird eineallgemeineInvoke-MethodedesDocument-Request-Brokersverwendet,dieamServervon derKlasse ��s��nsxLN�¢�90�Þt�E© ´ s�ÞE¨%2%�90 im-


plementiertwird. Zur UbermittlungdesRemote-Document-Callswird der Invoke-MethodeeineInstanzderKlasse LNâv^Üs��¢��2�w§s alsEingabeparameterubergeben.In derKlasseã�ä£â�åeæxçxçxè@éÏæsindallewichtigenInformationenfur denentferntenMethodeaufrufgekapselt.

Abbildung6.8:AufbaueinerSCA3D-Nachricht.

In Abbildung6.8 ist der Aufbau einerSCA3D-Nachrichtschematischgezeigt.Die Nachrichtenthalt vier Hauptkomponenten,die AuskunftuberdasaufgerufeneObjekt,die geforderteAktion,die Gute der Client-Anwendungund die aktuelleRechtesituationzwischenBenutzerund Servergeben.JedeKomponentekannweitereDatenenthalten,die dort jeweils angegebensind.Die Ein-gabeparameterderMethodewerdenmit Hilfe einerallgemeinenParameter-KlasseangegebenundamServer ausgewertet,sodaßbeliebigeKombinationenvon Eingabeparameternmoglichsind.DieRuckgabeparameterderOperationwerdenwiederumalsInstanzderKlasseêrè�ëtè%ì�æ�í æ�ë zurClient-Anwendungzuruckubertragen.

Im Abbildung6.9ist derAblauf beimAufruf einesRemote-Document-Calls(RDC)dargestellt.Ein Remote-Document-Callkannanjedesaktive 3D ObjektgesendetwerdenundumfaßtdieobenangegebenenMethoden.WelcheMethodebeimAbsetzeneinesRDC ausgefuhrt wird, wird durchdie lokale Anwendungmittels der Methode î%æ=í4æ=ëEìµï¦ðnæ=åÜæ�í ñ,òEî!ó¦ô ermittelt, indemdie EingabendesBenutzersund die PositiondesLevel-of-Information-Reglers ausgewertetwerden.Bei einemSelektionsereigniswird uberpruft, ob die Objektreprasentationeinesaktiven Objektesausgewahltwurde.Wenndieszutrifft, wird die bestimmteMethodemit der KennungdesInterface-Objektesund denParameterndurchAufruf der Methodeï¦ð9õ§òtö.æ=÷£øµäPó¦ô der Objektreprasentationund derMethodeï�ð9õ%òtö.æ�ó¦ô des ãÆùDæ=ðnæxäNòxð9í¿ëtòEú�ã)æ�ëEõ%è%ð9í -ObjektesamServer aufgerufen.Die KennungdesInterface-Objektesist in der ubergebenenSCA3D-Nachrichtenthalten.Am Server wird nun mitder Methode ûoï�ð?î�ü§ýKó¦ô daspassendeInterface-Objektgefundenund die beabsichtigteMethodedurch Aufruf von è=þ�þ!ú�ÿ§åÜæ�í ñ,òEî!ó¦ô auf dasentsprechendeInterface-Objektdes3D Dokumentesangewendet.Die ErgebnissederOperationwerdenzumClientzuruckubertragen.

Um diegewunschteMethodedesInterface-Objektesaufrufenzukonnen,werdenim FalleeinesRDC alle MethodennamendesbetreffendenInterface-Objektesmit der String-Versionder vomClient aufgerufenenMethodeverglichen.DasInterface-Objektselbstenthalt Referenzenauf dieaktive TeilgruppedesOriginaldokumentesundzur AusfuhrungderRDC-Methodenwird auf diesezugegriffen.


Abbildung6.9:Sequenzdiagrammfur denAufruf einesRemote-Document-Calls.

6.3.3 Die Level-of-Information-Komponenten

In diesemAbschnittwerdendieKomponenten,die fur dieModellierungdesLevel-of-Information-Ansatzesverwendetwerden,beschrieben.DieseKomponentenbauenaufdemDocument-Request-Broker-Modell auf und stellenFunktionalitat zur Transformationund Distribution von Objektre-prasentationenin verteiltenUmgebungenzur Verfugung.Hinzu kommenKlassenzur Performanz-messungim System,sodaßjedemBenutzerObjektreprasentationen zur Verfugunggestelltwerdenkonnen,dieseinenBedingungenambestenentsprechen.

Transformation von Objektr eprasentationen

Bei der AktivierungeinesDokumentobjekteswird automatischeineObjektreprasentationin derClient-Szeneangelegt. Die ReprasentationsformdesObjekteswird durchdie PositiondesLevel-of-Information-ReglersderClient-Anwendungbestimmt.DiesgeschiehtdurchAufruf derMetho-de éÏæ�í�ý£÷Pó¦ô mittels einesRDC mit einerSCA3D-Nachrichtals Eingabeparameter, die die aktu-elle Reglerpositionenthalt. Auf Server-Seitewird deraktuelleLoI ausgewertet,um die geeigneteObjektreprasentationzu erzeugen.Diesewird dannzur Client-AnwendungubertragenundmittelseinerPush-Operationvom Server in denClient-Szenengrapheingefugt. Der Aufbau der Metho-denschnittstelleeinesInterface-Objektesunddie Generierungvon Objektreprasentationensind imfolgendennaherbeschrieben:

� SchnittstelledesInterface-Objektes: Die Methodender SchnittstelledesInterface-Objekteskonnenin drei Gruppeneingeteiltwerden.Dies sind die Gruppeder Methodenzur Initia-lisierungdesInterface-Objektes,die Gruppezur Abfragevon InformationenuberdasDo-kumentobjektund schließlicheine Gruppezur Transformationdes DokumentobjektesinneueObjektreprasentationen. Da die Klasseder Interface-Objektevon der OpenInventor-KlasseãÆòtã)æ4þ!è%ëtè�í4ò¢ë abgeleitetist, erbteineInstanzauchalle Methodendieserubergeord-netenKlasse.In der Initialisierungsgruppe der MethodeneinesInterface-Objektesist ne-


ben den ererbtenMethoden,wie z.B. çxæ=í � è�ì�æ%ó¦ô zur Namensgebung, noch die MethodeùDò<þAÿ,äNñ,ï�ú�î@ë@æ�ð�ó¦ô enthalten,die eserlaubt,eineKopiealler UnterknoteneinesDokumentob-jektesals Kopie an dasInterface-Objektanzuhangen.Dadurchwird esmoglich veranderteObjektreprasentationen desOriginalobjekteszu erzeugenund zu verteilen,ohnedasOrigi-naldokumentzuverandern.

Die zweiteGruppevon Methodenumfaßtalle Methoden,die benotigt werden,damit eineBenutzerInformationenuber das Originaldokumentam Server abfragenkann. Diese In-formationen,wie z.B. Dokumentkennung,Komponentennamen,IPR-Daten,sind als Me-tadatenan dasDokumentangehangt. Die zugehorigen Methodensind z.B. é§æ�í4øºò¢ùDü%ø ó¦ô ,éÏæ�í4åIòEî%æ�ú � è%ì�æ�ç§ó¦ô oder é§æ�í4ü�êN÷£ü�ðnû*ò.ó¦ô . Beim Aufruf durch einenBenutzeruber einenRDC werdendieseMetadatenamServer ausgelesenundvon derClient-Anwendungausge-geben,z.B. in FormeinerTextausgabein eineigenesFenster.

� Generierungvon Objektreprasentationen: Die dritte MethodengruppebestehtausdenMe-thodenzurTransformationvon Objekten.Die wichtigsteMethodeist éÏæ�í�ý£÷Pó��æ=õ§æ�ú��¼òtû��ü�ðnû*ò¢ë¢ì}è%í¿ï�ò¢ð�ô , mit derdie Objektreprasentationerzeugtwird, die denangegebenenLevel-of-Information-Datenentspricht.DieseLoI-DatenbeschreibendenLevel unddie Auflosungder Objektreprasentation,die von einerClient-Anwendungangefordertwird. InnerhalbderMethodewird nundieseInformationausgewertetundeinentsprechendes3D Objekterzeugt.WennderOriginal-Level eingestelltist, werdendieOriginaldatendirektausgegeben.

Bei einemLevel,der3D-Netzenentspricht,wird ausdemOriginalobjektein3D-Netzmit derangegebenenAuflosungerzeugt.Der niedrigsteLevel, dernurNavigationim server-seitigenDokumenterlaubt,bewirkt, dasdasselektierteObjekt in der Server-Szenedurcheineein-gefarbteBounding-Boxmarkiertwird, sodaßdieseMarkierungamClientalsBildinformationsichtbarwird. NachdemeineObjektreprasentationerzeugtwurde,wird dieseim Austausch-format(OpenInventor-Format)alsStringausgegebenundmittelseinerremote-zuganglichenMethodederClient-Anwendung,die vom Server aufgerufenwird, in die Client-Szeneinte-griert.

ZurGenerierungderObjektreprasentationenwerdenOpenInventor-Methoden verwendet.AlsBeispiel sei die 3D-Netzerzeugungbeschrieben.Zur Erzeugungvon 3D-Netzenwird mitHilfe einer Aktion ( ã/ò@äNè%ú�ú��Gè%ù�ö��ù<í¿ï�ò¢ð ) ein Callback( ãÆò�vë¢ï�è�ð*é%ú�æ¢ä�� ) auf den betref-fendenObjektknotenangewendet,wobeidurchEckpunktbestimmungein DreiecksnetzmiteinerfestzulegendenAuflosungerzeugtwird. DiesesNetzwird dannaneinenã/ò@ãÆæ þ!è%ëEè%í4òxë -KnotenangehangtundalsRuckgabederMethodeéÏæ�í�ý£÷Pó¦ô ausgegeben.

Performanzmessungund -auswertung

DiePerformanzmessungberuhtaufderBestimmungvonlokalerundRemote-Framerate.Außerdemwird die GroßederClient-Szenebenotigt, um die BelastungderClient-Anwendungeinordnenzukonnen.Zu diesemZweckist aufClient-Seiteeineêræ=ëtû*ò¢ëEì}è%ð?ùDæ -Klasseangelegt, diezurBestim-mungvon lokalerFramerateundSzenengroßeMethodenbereitstellt.Die SteuerungderMessungund die Anzeigeder Meßergebnissegeschiehtmit Hilfe desClient-Panel-GUI,dasin Abbildung6.3alsSichtaufdieBenutzerschnittstelle vonSCA3Dgezeigtist.

Die lokaleFrameratewird ermittelt,indembei jederRendering-AktioneinZahlerheraufgesetztwird, derdie Bildanzahlreprasentiert.DurchgleichzeitigeMessungeinerStart-undStopzeitwirdfur einenMittlungszeitraumdie lokaleFramerateausdemVerhaltnis von Bildern pro Zeiteinheit


bestimmt.Um diemaximalmoglicheFrameratebestimmenzukonnen,mußsichdieSzeneoderdieKamerabewegen,anderenfalls waredie sogemesseneFramerategleichNull. Daherwird fur eineMessungderLeistungdesSystemseinekunstlicheBewegungderKameravorgenommen.WenneinDokumentdynamischeKomponentenenthalt oderderBenutzerwahrendderMessungmit demDo-kumentstandiginteragiert,ist diesnichtnotig.Die GroßederClient-Szenewird durchAnwendungeiner äNò� !ð9í�vë¢ï�è�ð*é%ú�æ¢ä�� -Aktion desOpeninventor-API gemessen.In Abbildung 6.10 sind dieAblaufewahrendeinerPerformanzmessungeinerClient-AnwendungalsSequenzdiagrammdarge-stellt. Die Messungwird nicht kontinuierlichdurchgefuhrt, sondernbeim Anmeldenund danninbestimmtenZeitabstandenaufgerufen.Die Ergebnissewerdenim Client-Panel-GUIangezeigt.

Abbildung6.10:SequenzdiagrammderAblaufebeimPerformanztesteinerClient-Anwendung.

Die Bestimmungder Remote-Framerategeschieht,wie in Abschnitt5.8.1angedeutet,durchzeitlicheMarkierungvon Aktionen und dendazugehorigenBilddaten.Dazuwird am Client ei-nerAktion eineeindeutigeKennungzugeordnetundzusammenmit demStartzeitwertgespeichert.SolangedieseEinzelmessunglauft wird keineneueAktion markiert.Die Aktion wird als EventzumServer ubertragenunddortaufdasDokumentangewendet.Die mitgesendeteAktionskennungunddie Client-Kennungwird nachderAusfuhrungin dasnungerenderteBild alsmarkierterPixeleingebracht.Diesgeschiehtdurchdie Methode�æ��Aí� Aë@æxä��µó¦ô der Update-Klasseam Server, diefur die Erzeugungder BilddatendurchOffscreen-Renderingzustandigist. Auf Client-Seitewird,wahrendeineEinzelmessunglauft, jedesBild auf denZustanddesMarkierungspixels hin unter-sucht.Hierfur wird die Methodeù�ñAæ�ù�öÏ÷Næ�ì}ò¢í4æ�øºæ�ú�è�ÿ9ó¦ô derClient-Klasse��þ!î�è%í æ verwendet,diedasBild als Textur auf die Projektionsflacheder Client-Szeneabbildet.Wenndie aktuelleAkti-onskennungund die eigeneClient-Kennungim Bild vorhandenist, wird die Stopzeitder Aktionbestimmtunddarausdie GesamtdauerderAktionsausfuhrungunddamitdie Remote-Verzogerungerrechnet.

Da die Texture-Mapping-Rate,mit der Bilddatenauf die Projektionsflacheder Client-Szeneabgebildetwerden,variableregelbarseinsoll, kannsie durchdie Methode ç¢æ�í�våÜãÆú ï�î%æ�ë,ó¦ô derKlasse ä£êNè%ðnæ=ú¦ãÆæ=ëEõ%è%ð9í dynamischeingestelltwerden.Die Regulierungerfolgt entwederuberdasClient-Panel-GUIdurchdenBenutzeroderautomatischdurchdie Client-Anwendung.Um die


server-seitigeRendering-Rateandie Texture-Mapping-RateeinerClient-Anwendunganzupassen,kannubereineremote-aufrufbareMethodedesServersdieServer-FrameratevomClientauseinge-stellt.DurcheineRegelkreispaßtsichdasSystemsoan,daßdie Texture-Mapping-RatemoglichstderoptimalenRemote-Framerateentspricht.

Modellierung desIPR-Filters zum Sicherheitsmanagement

Eswird davon ausgegangen,daßdie benotigtenMetadaten,hier kurz mit IPR-Information(Intel-lectualPropertyRights-Information)benannt,zumSicherheitsmanagementin einerDatenbankamServer vorliegen.Beim EinleseneinesDokumentesdurchdenServer einesdigitalenBibliotheks-systemswerdendieseInformationenin dasinterneDokumentmodellintegriert. An dieserStellewerdenzwei EbenendesSicherheitsmanagementsunterschieden.Zum einendie IntegrationderIPR-InformationdurchAnhangenvon Textkettenbzw. Signaturenin Form einesAttributobjektes(Label Object) andenGruppenknotendesbetreffendenObjektes(Ebene1) . Zum anderendurchEinbettungderIPR-InformationalsWasserzeichenin dieObjektdatenselbst(Ebene2).

Zunachstsoll derEntwurfvon Ebene1 beschriebenwerden.Beim EinleseneinesDokumenteswerdendie IPR-Informationenausder Datenbankextrahiertund in dasinterneDokumentmodellintegriert.Fur 3D Dokumentewird diesesDokumentmodellvomSzenengraphderVisualisierungs-anwendungvorgegeben.

Abbildung6.11:IntegrationdurchVerwendungeinesAttributknotensunddurchKonstruktioneinesInterface-Objektes.

In Abbildung6.11ist dieIntegrationderIPR-Informationin denSzenengraphdargestellt.Dabeiwird ein Attribut-Knotenin die ubergreifendeGruppedesbetreffendenObjekteseingefugt. DieserLabel-Knotenenthalt alsStringdieobenangegebeneIPR-Information.

Um die so integrierte Informationim Falle der SelektiondesObjektesdurcheinenBenutzerwirksam zu machen,wird das Interface-ObjektdesGruppenknotensin der Weiseerzeugt,daßesals zusatzlicheDatendie IPR-Informationenthalt und Methodenzum Sicherheitsmanagementbereitstellt.DiesesVorgehenwird von demin Abschnitt6.3.2vorgestelltenDocument-Request-


Broker-Ansatzunterstutzt.WenndasObjektmit Hilfe derClient-Anwendungselektiertwird, stehtdemBenutzerdaszugehorigeInterface-Objektmit seinenMethodenzurVerfugung,umunterande-remObjektreprasentationenzuubertragenoderdieMetadatenabzufragen.DurchdenVergleichderIPR-InformationenunddieRechtedesBenutzers,diemit seinerAktion ubertragenwurden,sindnurdiejenigenMethodenzuganglich,diedieSchutzrechtedesObjektesnichtverletzen,z.B.dieMetho-degetOR(LoI=KlasseB) im FallevonKlasseB- Objekten.Dabeiwird dasKlassifizierungsschema(Document-Distribution-Classes) ausAbschnitt2.4.4verwendet,dasregelt, auf welcheWeisedieObjektdatenverteilt werdendurfen.Auf dieseWeisewird ein Filter (Abbildung6.11: IPR-Filter)fur Objektdatenrealisiert,durchdenderZugriff derBenutzerkontrolliertwerdenkann.

ZumVergleichderIPR-Informationenmit denRechteneinesBenutzerswird eineSignaturver-wendet,die derClient bei derRegistrierungamServer erhaltenhat.DieseSignatur, die unteran-deremdie Benutzerrechtein codierterForm enthalt, wird lokal vom BenutzervorgehaltenundmitjederAktion zumServer ubertragen.Die SignaturdesClientsist ebenfalls amServer gespeichertundkannsozur IdentifikationdesBenutzersundzumAbgleichderRechteherangezogenwerden.DurchentsprechendeVerschlusselungderSignaturwird diesesVerfahrensichergegenManipula-tionenvonaußen.

Nun wird auf denEntwurf von Ebene2 zur Einbettungvon Wasserzeichenin 3D Objekteein-gegangen.DieseEbenedesSicherheitsmanagementsbautaufdemvorherbesprochenenAnsatzderInterface-Objekteauf. Genauwie in Ebene1 werdendie IPR-InformationenalsAttributknotenindenSzenengraphintegriert. Bei derErzeugungdesInterface-ObjekteswerdennunallerdingsMe-thodenzur Verfugunggestellt,dieeineEinbettungvon Wasserzeichenin dieObjektdatenermogli-chen.DieseMethodenwerdenautomatischausgefuhrt,wenneinBenutzereineObjektreprasentati-onerzeugenundubertragenmochte.

DasInterface-Objektwird, wie obenbeschrieben,alserweitertesGruppenobjektangelegt, in-demesvoneinerOpenInventorGruppen-Klasse(SoSeparator) abgeleitetwird undzusatzlicheDa-ten und Methodenenthalt. Es wird mit der Kennungder erlaubtenIPR-Klasseals Konstruktor-ParameteramServer erzeugtunddemClient ubereineCORBA Objektreferenzbekanntgemacht.Durchdie IPR-Klasseunddie Client-Signaturwird die Verfugbarkeit derMethodendesObjektesgesteuert.Auf dieseWeisekannein Benutzernur mit denerlaubtenObjektreprasentationen arbei-ten.

6.3.4 Die Komponentender Bilddatenschicht

In diesemAbschnitt wird die Verteilungvon Bilddaten in der SCA3D-ArchitekturanhanddesEntwurfsder Bilddatenschichtbeschrieben.Auf Server-Seitewerdenvom Offscreen-Rendering-Prozeßmit der eingestelltenServer-FramerateBilder erzeugt,die die Ergebnisseder Beleuch-tungssimulationdes3D Dokumentesdarstellen.DieseBilddatensollen auf Client-Seiteauf diein der SzeneenthalteneProjektionsflache abgebildetwerden.Dafur mussensie an jede ver-bundeneClient-Anwendunggesendetwerden.Die Verteilung der Bilddaten soll jedoch ohneAbhangigkeit zwischendeneinzelnenUbertragungsprozessen stattfinden,um zu verhindern,daßdie langsamsteUbertragungalleanderenVerbindungenbremst.Die BilddatenwerdenuberSocket-Verbindungenmit dem TCP/IP-Protokoll bzw. mit dem UDP-Protokoll gesendet.Es werdenUnicast-Verbindungenverwendet,d.h. fur jedenTeilnehmerwerdendie Bilddatenseparatuber-tragen.Multicast-Verbindungenwerdennicht verwendet,weil dieMoglichkeit bestehensoll, jedenBenutzermit einerunterschiedlichenBilddatenratezuversorgen.

Der Aufbau der Bilddatenschichtist in Abbildung 6.12 gezeigt.Die Bilder werdenvon derMethode ��þ!î%è�í æ�ó¦ô der Server-Anwendungin einenBild-Ringbuffer geschrieben,der eine Ent-


Abbildung6.12:AufbauderBilddatenschichtderSCA3D-Architektur.

kopplungvon BilderzeugungundBildubertragungfur jedenBenutzerzulaßt.

Abbildung6.13:SequenzdiagrammdesVerbindungsaufbausunddesBilddatenaustausches

Beim AnmeldeneinesBenutzerswird ein eigenerRingbuffer fur diesenangelegt und in einerInstanzder Klasse ä£ú�ï�æ=ð9í��ï�ç�í�� ú�æ=ì�æ�ð9í , die fur jedenBenutzergeneriertwird, abgelegt. Eben-falls auf Server-Seiteliest eine Instanzder Klasse ü@ì}è�é§æxãÆæ=ëEõ%è%ð9í , die von der �ñ.ë@æ�è%î -Klasseabgeleitetist undalseigenstandigerProzeßablauft, die Bilder ausdemjeweiligenBild-Buffer ausundschreibtsieauf die Socket-VerbindungzwischenServer undClient. Auf Client-Seiteliest ei-ne Instanzder Klasse ü�ì}è@é§æ¢ä£ú�ï�æ=ð9í , die ebenfalls als eigenstandigerThreadarbeitet,von dieserSocket-VerbindungdieBilddatenundschreibtsiein eineninternenSpeicherbereich.Vondortwer-dendie Bilddatenvon einerInstanzderKlasse ��þ!î%è�í æ derClient-Anwendungals Textur auf die


Projektionsflacheabgebildet.In Abbildung6.13ist dasSequenzdiagrammdesVerbindungsaufbausunddesZugriffs aufden

Ringbuffer beim Bilddatenaustauschgezeigt.Bei der AnmeldungeinerClient-AnwendungwirdeineSocket-Instanzerzeugt,dieeineConnect-AuforderungandenwartendenServer-Socketsendet.DerServer-Socket reagiertdurcheine è%ùDù�æ4þAí�ó¦ô -MethodeundbauteineSocket-Verbindungmit derangegebenenPort-Nummerauf. Anschließendwird eine Instanzder Klasse ü�ì}è@éÏæxãÆæ=ë¢õ§è�ð9í alsThreadauf Server-Seiteerzeugt,die die neueSocket-Instanzals Eingabeparameterubernimmt.Parallelwird derBild-Ringbuffer mit dergefordertenBildauflosunginitialisiert. Nun konnenvonder ��þ!î%è�í æ -InstanzBilddatenmit derServer-Frameratein denRingbuffer geschriebenwerden,diewiederumvon dem ü@ì}è�é§æxãÆæ=ëEõ%è%ð9í -Threadentsprechendder an denClient angepaßtenBildrateausgelesenwerden.Auf einenBuffer-Uberlaufbzw. ein leerenBuffer wird durcheinenAusnahme-Aufruf reagiert.

6.4 Zusammenfassung

In diesemKapitel wurdendie Schrittebeim Entwurf einer Software-Architekturallgemeinvor-gestellt und die Vorteile der Verwendungder SpracheUML im Entwicklungsprozeßverdeut-licht. Fur die Software-ArchitekturSCA3D wurdendie Anforderungenan dasSystemmit Hil-fe von UML-Diagrammenbeschriebenund Sichtenauf dasSystemausBenutzerperspektive ge-zeigt.Darananschließendwurdedie DesignphasedesEntwicklungsprozessesebenfalls mit UML-Diagrammenerlautert.Dabei standendie Visualisierungskomponenten, der Dokument-Request-Broker, die Level-of-Information-Komponenten unddie Bilddatenschichtim Vordergrund.Im fol-gendenKapitel wird nundie ImplementierungsphasedesEntwicklungsprozessesbeschriebenunddieRandbedingungenderHardware-undSoftware-Umgebungin denEntwurfmiteinbezogen.AmEndedesKapitelswird die Software-ArchitekturSCA3Dalsein verteiltesobjekt-orientiertes Sy-stemmit einerSoftware-technischenRealisierungin einerHardware-Umgebungbeschriebensein.

Kapitel 7

Implementierung der Ar chitekturSCA3D

In diesemKapitel wird die Implementierungder Software-Architekturfur skalierbareSzenenbeschrieben.Die verwendetenWerkzeuge,die erstelltenund benutztenHard- und Software-Komponentenunddie KommunikationzwischendenKomponentenwerdenim Detail dargestellt.Da im Vorfeld derEntwicklungdesSCA3D-KonzepteseineVorgangerarchitektur erarbeitetwur-de, die denZugriff auf server-seitige3D Modelle uberVideobjektreprasentationen erlaubt,wirddieseals ImplementierungeineserstenPrototypenkurz beschrieben.Darananschließendwird dieImplementierungderSCA3D-Architekturalsobjekt-orientiertes verteiltesSystemerlautert.

7.1 Einf uhrung

Die Software-ArchitekturSCA3Dsoll moglichstplattform-unabhangigrealisiertwerden.Fur ver-teilte Systemebietetsichhierfur derCORBA-Standardzur objekt-orientiertenEntwicklungan,daer, wie in Kapitel3.3beschrieben,Technologietransparenzermoglicht.DadurchkonnenauchKom-ponenten,die in unterschiedlichenProgrammiersprachenentwickelt werden,in einemverteiltenSystemzusammenarbeiten.Zur Realisierungvon SCA3Dwird die CORBA-ImplementierungJa-vaIDL desJava-Developement-Kitsverwendet.Die Software-Komponentensindin Java geschrie-benund laufendamitohnegroßereAnpassungenauf allenPlattformen,fur die eineJava-Virtual-Machine existiert. Die Visualisierungskomponenten in SCA3D sind mit demOpenInventor APIumgesetztworden.Die eigentlichenKlassendesVisualisierungs-APIsindin C++ geschriebenundwurdenmit Hilfe einesJava-Native-Interfaces[Lia99] in die Java- Klasseneingebunden.Dadurchwird eine hohereGeschwindigkeit bei der Visualisierungermoglicht und die Vorteile der Java-Programmierungwerdengleichzeitigausgenutzt.Allerdingswird hierdurcheineeigeneRuntime-Umgebungfur dasOpenInventor-API auf jederPlattformbenotigt unddiePlattformunabhangigkeitwird zumTeil aufgegeben.Alternativensinddie Verwendungeinervollstandigin Java implemen-tiertenOpenInventor-Klassenbibliothek (z.B. 3D-MasterSuiteJavaderFirmaTGS)oderderJava-eigenenVisualisierungsbibliothek Java3D(siehez.B. [SRD98]).

7.2 Verwendungvon Software-und Hardware-Werkzeugen

Die Software-ArchitekturSCA3D bestehtausmehrerenSchichten,die mit Hilfe verschiedenerWerkzeugeumgesetztwerden.Dies sind die HTTP-Kontrollschicht,die Visualisierungsschicht,

110

KAPITEL 7. IMPLEMENTIERUNG DERARCHITEKTUR SCA3D 111

dieDokumentkontrollschicht unddieBilddatenschicht.Die verwendetenSoftware-undHardware-ToolszurRealisierungderArchitekturSCA3Dwerdenin diesemAbschnittbeschrieben.

7.2.1 3D Visualisierung: DasRadiance-Systemund die OpenInventor-Bibliothek

Fur die 3D Visualisierungbzw. dasRenderingvon 3D Modellenwurdenim Laufe der ArbeitenzweiunterschiedlicheWerkzeugeverwendet.AnfanglichwurdedieRaytracing-SoftwareRadiance[War94] benutzt,die mit einemrelativ hohenZeitaufwand physikalischkorrekt berechneteBe-leuchtungssimulationen erzeugenkann.Fur die EntwicklungderSCA3D-Architekturwurdedannim folgendendie szenengraph-basierte Visualisierungsbibliothek OpenInventor [Wer98] benutzt,die zwar nur die Moglichkeit eineslokalenBeleuchtungsmodellesbietet,dafur abermit interakti-venBildwiederholratenaufwartenkann.BeideWerkzeugewerdennunnaherbeschrieben.

� Radiance: DaderRaytracing-AlgorithmusvonRadianceSpiegelungen,TransmissionenunddiffuseReflexion durchAusbreitungvon virtuellenLichtstrahlennachbildet,wirken die er-zeugtenBilder des3D Modells sehrrealistisch.Allerdingswird dafur in Kauf genommen,daßkeine wirklich interaktive Visualisierungmoglich ist. Trotzdembietet die modifizier-te Raytracing-SoftwareMoglichkeitenzumErzeugenvon Objektmasken,sodaßBildobjektemit KonturinformationalsReprasentationzumClient ubertragenwerdenkonnen,diedortalsObjektreferenzdienen.DienotigenModifizierungsschrittewurdenfurdieRadiance-Softwaredurchgefuhrt unddamitdieCodierungvonVideoobjektenalsReprasentationvon3D Objek-tenin einerverteiltenUmgebungmit Hilfe einesMPEG-4Videocodecsermoglicht.

Radiancestellt keineVisualisierungsbibliothek (API) zur ErweiterungandererProgrammemit 3D Visualisierungsfunktionalitat dar, sondernist als eigenstandigesRendering-Systemzum Einsatzin den BereichenLichtdesignund Architektur entwickelt worden.Der Pro-grammcodeist nicht objekt-orientiertund wurdein der ProgrammierspracheC entwickelt.RadianceverwendetrekursivesRaytracingmit einigenErweiterungen,umdieBeleuchtungs-simulationmit einemoptimalenVerhaltnisvonGenauigkeit undGeschwindigkeit zuberech-nen.Da derQuellcodefrei zuganglichundgut dokumentiertist, konntedasSystemerfolg-reich an die Aufgabenin der Praxisund im wissenschaftlichenUmfeld angepaßtwerden.Dadurchist esheuteein weitverbreitetesWerkzeugzur Erzeugungvon physikalischrealisti-schenBildernvon 3D Oberflachenmodellenundzur numerischenAuswertungvonBeleuch-tungssituationenin virtuellenWelten.

� OpenInventor: Zur EntwicklungverteilterUmgebungen,die 3D Visualisierungfur mehrereBenutzerunterstutzensoll, mußdieverwendeteVisualisierungsbibliothek interaktive Frame-raten,d.h. moglichsteineBildwiederholratevon 25 bis 30 Framespro Sekunde,erlauben.DennderEindruckeineskooperativenArbeitsprozessesin verteiltenUmgebungenkannnurdurchinteraktive Frameratenbei der3D Visualisierungaufrechterhaltenwerden.JederTeil-nehmereinerVisualisierungskonferenz solltedieAktionenderanderenTeilnehmermit einerminimalenVerzogerungszeitwahrnehmenkonnen,dieeineobereSchranke nicht uberschrei-tet. Um solcheFrameratenzu erreichen,kann ein Rendering-Systemmit einemglobalemBeleuchtungsmodellnicht verwendetwerden.DaherarbeitenVisualisierungs-APIs,wie dievon der Firma SGI entwickelte OpenInventor-Bibliothek, mit einemlokalenBeleuchtungs-modell,bei demunteranderemkeineSchattenoderReflexionenberechnetwerden.Zur Be-leuchtungssimulation wird die in Abschnitt3.2.2durchFormel 3.5 angegebeneGleichunggelost,d.h.OpenInventorbenutztalsStandarddasPhong-Beleuchtungsmodell.


Abbildung7.1:Die OpenInventor-Architektur nach[Wer98]

OpenInventor stellt eine Bibliothek von objekt-orientierten Klassenzur Verfugung, dieeseinemAnwendungsprogrammiererermoglicht, interaktive Graphikanwendungenzu ent-wickeln.DasOpenInventor-Systemist in C++ geschrieben,bietetaberauchdieMoglichkeitzur Entwicklungin der SpracheC. Durch VerwendungeinesJava-Native-InterfacekonnenaußerdemGraphikprogrammemit OpenInventorvollstandigin Java entwickelt werden.ZurZeit sinddiebekanntestenSchnittstellenzwischenOpenInventorundJavadie3D MasterSui-te for JavaderFirmaTGSunddie frei verfugbareSchnittstelleKahlua [WK96], die von anderBrown University(USA)entwickelt wurdeundnunvomInstitutfur ComputergraphikderFraunhofer-Gesellschaft weiterbetreutwird. Die BasisarchitekturdesOpenInventor-Systemsist in Abbildung7.1dargestellt.

Zur VerdeutlichungderFunktionsweisedesOpenInventor-API soll hier dasKonzeptder in-ternenSzenendatenbankundderAnwendungvon AktionenaufdeninternenSzenengraphennahererlautertwerden.Die Basiseinheitder von OpenInventor verwendetenSzenendaten-banksinddieKnoten,diezumAufbaueiner3D Szenebenutztwerden.EinealsBaumstrukturgeordneteZusammenstellungvon Knotenwird alsSzenengraphbezeichnetundstellt einengerichteten,azyklischenGraphdar. Bei einemgerichteten,azyklischenGraphwird fur dieBaumstruktureineRichtungvorgegeben,mit dermanvon einemKnotenubereineVerbin-dungzum nachstenKnotengelangt.Außerdembeginnt und endetkein Pfad im GraphmitdemselbenKnoten,d.h. esexistierenkeinegeschlossenenPfade.Wird eineAktion auf denOpenInventor-Szenengraph angewendet,sowird er von obennachuntenundvon links nachrechtsdurchgegangenunddieAktion aufalleKnotenangewendet.

Die SzenendatenbankspeichertundverwalteteinenoderauchmehrereSzenengraphen.DieDatenbankentitatenbzw. -primitive stellenForm-Knoten(ShapeNodes) (z.B. Kugel,Cone,Zylinder, Quad-Mesh),Eigenschaftsknoten(PropertyNodes) (z.B. Material,Beleuchtungs-


Abbildung7.2:HierarchiederSoAction-KlassenvonOpenInventor

modell, Texturen) und Gruppen-Knoten(Group Nodes) (z.B. Separator, Level-of-Detail,Schalter)dar. Zusatzlich kannein Szenengraphin der DatenbankauchSensoren(Sensors)undsogenannteMaschinen(Engines) enthalten,mit denenKnotenverknupft, Zustandsande-rungendetektiertund dynamischeSzenenerstellt werdenkonnen.Wenn eine Aktion an-gewendetwird (z.B. SoGLRenderAction, SoGetBoundingBoXAction, SoWriteAction), wirdvon derDatenbankderaktuelleZustand(Traversal State) in einemeigenenObjektverwal-tet und die Veranderungder Zustandsparameterdurchdie Knotenprotokolliert. Die Ande-rung desTraversal-Statesdurchdie Knoten beim DurchgangdesSzenengarphenfuhrt imErgebniszu der interaktiven Visualisierung,die vom Benutzerwahrgenommenwird. JederKnotenimplementiertdabeiein Aktionsverhalten,dasdurchseineKlassedefiniertwird. Sowird dasVerhaltenim FalleeinerSoGLRenderAction, die zur Ausgabevon gerendertenBil-dernderSzenenobjektefuhrt, von einemGruppenknotenalsTraversierungderUnterknotenundanschließenderWiederherstellungdervorherigenZustandesimplementiert.EinMaterial-Knoten andertdagegen die Zustandswertefur dasMaterial im Traversal-State.WenneineFormknotenerreichtwird, wird dessenGeometriemit denParameterndesTraversal-StategerendertunddieBilddatenausgegebenbzw. gespeichert.AktionenkonnenaufKnoten,Pfa-deundListenvonPfadenangewendetwerden.

OpenInventor bietet eine Austauschformatfur Szenen,das den Aufbau des Szenengra-phen mit einer festgelegten Syntax wiedergibt. DiesesFormat kann als AusgabeformatdesDatenmodellsdesSzenendatenbankangesehenwerden.Beim Einleseneiner solchenOpenInventor-Datei (Suffix: *.iv), wird dieseInformationaufdie interneDatenbankderAn-wendungabgebildetund somit die 3D Szenefur die interaktive Visualisierungzuganglichgemacht.EineSzenekannin eineAusgabedateigeschriebenwerden,indemein SoWriteAc-tion auf ihrenPfadangewendetwird. Aus demOpenInventor-Austauschformat wurdeauchdasVRML-Formatfur 3D Visualisierungsanwendungen im WWW-Umfeldentwickelt.


7.2.2 Hardware-Komponenten

In diesemAbschnittwird die Entwicklungs-undTestumgebungderSoftware-ArchitekturSCA3Dvorgestellt.DabeiwerdendieverwendetenRechnermit ihrerHardware,denBetriebssystemenundder jeweiligenNetzanbindungbeschrieben.Alle KomponentenderArchitekturarbeitenauf Unix-und Windows-Systemen,da zur Entwicklungdie plattform-unabhangige SpracheJava verwendetwird. AllerdingsverlangtdasOpenInventor-API eineeigeneRuntime-Versionauf jedemBetriebs-system.

Da die Entwicklungsumgebung mit Runtime-Lizenzenfur Windows-, SGI-Irix- und Sun-Solaris-Betriebssystemeausgestattetwurde,konnenalle Komponentenbeliebig verteilt werden.Allerdings wurde im Verlauf der Entwicklung eine Verteilunggewahlt, bei der ein Server aufUnix-Maschinen(Unix-Workstation:Sun-Solaris)unddie Client-AnwendungenhauptsachlichaufWindows-Rechnern(PC: WindowsNT, Notebook:Windows98) betriebenwurden.Einige Testswurdenauchmit spezialisiertenGraphikmaschinenvon SGI alsServer vorgenommen.Die Anpas-sungauf spezialisierteGraphik-Hardwarewurdeallerdingsnicht vertieft, um die Einsatzmoglich-keitenderSoftware-Architekturnicht schonin derEntwicklungsphaseeinzuschranken. In Tabelle7.3 ist eine Zusammenstellungder verwendetenMaschinenin der Entwicklungsgumgebung ge-zeigt.

Abbildung7.3:BeschreibungderHardwarederEntwicklungsumgebung.

Die Entwicklungund die meistenTestswurdenin demLAN (Local Area Network) desIn-stitutsfur MedienkommunikationderGMD durchgefuhrt. Alle obenaufgefuhrtenRechnerwarenuberein Ethernetmit einerBandbreitevon maximal100MBit/svernetzt.Der verwendetemobilePC(Notebook) konntealternativ uberein Modemmit 56kBit/sangeschlossenwerden.Zusatzlichzum Ethernet-LANwar ein ATM-Netz mit maximal622 MBit/s Bandbreiteverfugbar. Die bei-denobenaufgefuhrtenUnix-Maschinenwarensowohl andasEthernet,alsauchandasATM-Netzangeschlossen.Mit Hilfe derATM-TechnologiekonnteeineVerbindungzwischenSCA3D-ClientundSCA3D-Serveraufgebautwerden,beiderdieBandbreiteregulierbarwar. DerBereich,in demdie Bandbreitevariiert wurde, lag zwischen128 kBit/s und 100 MBit/s. Eine ATM-Verbindungzeichnetsichweiterhindadurchaus,daßdieangeforderteBandbreiteauchgarantiertwerdenkann,d.h. vollstandig fur die Client-Server-Kommunikationzur Verfugungsteht.Im Ethernetbzw. imheterogenenInternetist diesnichtderFall, daessichumBest-Effort-Verbindungenhandelt.


Abbildung7.4:Zugriff auf server-seitige3D ObjekteuberdieKennungvonVideoobjekten

7.3 Realisierung des ersten Prototypen: Remote-Rendering uberMPEG-4 Videostrome

Zunachstsoll einereineRemote-RenderingArchitekturvorgestelltwerden,beiderdie3D Geome-triewahrendderVisualisierungvollstandigaufdemSerververbleibt.Hierzuwird einserver-seitigesVisualisierungsmodulentworfen, das3D Geometrieeinliest und darausBilder durch Renderingerzeugt.DieseBildinformation wird an die Client-Rechnerubertragenund dort mit Hilfe einesDisplaysangezeigt.Der Benutzerhat die Moglichkeit ubereinenRuckkanalzum Server die 3DVisualisierungdort zu steuern,indemer zumBeispieldie Kamerapositionoderdie Bildparameterandert.Manipulationder 3D ObjekteselbsterforderteineMoglichkeit zur ReferenzierungdieserObjekteanhandihrerObjektkennungdurchdieClient-Anwendung.Die dazubenotigtezusatzlicheInformationkann,wie im folgendenbeschrieben,durchVerwendungvon objekt-basierterVideo-codierungbei der Bildubertragunggeliefertwerden.Ein objekt-basierterVideocodecerfullt hierzwei Funktionen,indemdie Datenmengereduziertwird undgleichzeitigObjektinformationerhal-ten werdenkann.Bei dieserArchitektur wird dasvisuelleFeedbackfur die Interaktionnur uberdie Bildinformationvon Server gegeben,dahermussenProblemedurchunvermeidliche,zeitlicheVerzogerungseffekte bei derNetzubertragungberucksichtigtwerden.Die Ergebnisse,die mit die-semAnsatzerzieltwurden,sindin [Loe00a] beschrieben.Zur SteuerungdieserverteiltenVisuali-sierungsanwendungwird einProtokoll zurRuckubertragungvonKontrollbefehlenbenotigt, dasmiteinerSchnittstelleder server-seitigenGraphikanwendungkommuniziert.Auch die BildparameterderCodierungwerdenuberdiesesProtokoll kontrolliert.

Beim Visual-Interaction-Approach (VIA) [Loe00a] zur verteilten3D Visualisierungwird ein3D Modell auf demServer-Rechnergerendertund ein visuellesFeedbackin Form von codiertenBildernzumClient ubertragen.Dieserkannmit Hilfe einesRuckkanalsdieVisualisierungsanwen-dungam Server steuern,indemer z.B. denBlickpunkt oder-winkel andertoderdie Szeneselbstmanipuliert.Der Zugriff aufdie 3D ObjekteamServer erfolgt in diesemFall uberdie im MPEG-4VideostrommitgelieferteKennungderVideoobjekte.Ein ObjektkannamClient fur die Interaktionselektiertwerden,sodaßesalsVideoobjektin einenseparatenElementarstromcodiertwird. Hier-durchist am Client die Kontur- , Textur- und BewegungsinformationeinesselektiertenObjektesverfugbar. Der Benutzerkannnun eine3D Aktion festlegen,die mit der Objektkennungund denTransformationsparameternzumServer ubertragenwird unddort auf das3D Modell angewendetwird. DurchdieseMethodekanneinBenutzermit der3D GeometrieinteragierenohnedieGeome-


triedatenselbstauf seinenRechnerubertragenzu mussen.Alternativ zu einemselektiertenObjektkonnenauchallesichtbarenObjekteeinerSzenedynamischin ElementarstromeeinerMPEG-4Vi-deoszenecodiertwerden.Der MPEG-4Standarderlaubtmaximal1024Objektein einerSzene,sodaßInteraktionmit denObjektendessichtbareBereicheines3D Modellsmit dieserMethodemiteinergutenAuflosungrealisiertwerdenkann.In Abbildung7.4 ist die Ubertragungvon MPEG-4Elementarstromenunddie Referenzierungvon 3D Objektenmit Hilfe derKennungenderVideo-objekteamClientveranschaulicht.

Die wesentlichenKomponentenfur diesenAnsatzsind auf der Server-Seiteein 3D Rende-rer, ein MPEG-4Videocoderund eineServer-Anwendungzur Ubertragungder Videostromeundzum Empfangder Benutzeraktionen.Auf Client-Seitewird ein MPEG-4Videodecoderund eineinteraktive Display-Anwendungbenutzt,umdieVideostromezudecodieren,in derrichtigenWeisezusammenzusetzenundumdieClient-Interaktionmit derSzenezuermoglichen.DieseIdentifizie-rung von Objektenerfolgt bei der KompositiondesGesamtbildes,indemdie Shape-Informationmit deraktuellenZeigerpositionunddemModusderMauseingabeverglichenwird. Ausdenerhal-tenenAktionsparameternwird eineAktionsnachrichtzusammengebaut,die nebenderObjekt-undBenutzerkennungauchdieFrame-Nummer, dieTransformationskennung undeine3D Transforma-tionsmatrixenthalt. DieseAktionsnachrichtenwerdenubereinenRuckkanalzum Server ubertra-genunddort ausgewertet,bevor sieandie Visualisierungsanwendung weitergegebenwerden.ZurzeitlichenSynchronisationwird die mitgelieferteFrame-NummerderNachrichtverwendet,sodaßzeitlicheVerzogerungenim Netzberucksichtigtwerdenkonnen,auchwennmehrereBenutzeraneinerSzenearbeiten.

7.4 Implementierung der SCA3D-Architektur fur den Level-of-Inf ormation-Ansatz

Aufbauendauf den Ergebnissenaus der Umsetzungdes erstenKonzepteswird die Software-ArchitekturSCA3Dfur skalierbareSzenenimplementiert,wobeiRemote-VisualisierungundlokaleVisualisierungkombiniertwerden.Zur 3D Visualisierungwird dieOpenInventorSoftwarebenutzt,da sie fur interaktive Visualisierungsanwendungen aufgrundder erreichbarenBildwiederholratenbessergeeignetist. Die Umsetzungerfolgt in derobjekt-orientiertenProgrammierspracheJavaundzurEntwicklungwird die in Abschnitt7.2.2angegebeneHardware-Umgebunggenutzt.

7.4.1 DasSchichtenmodellder SCA3D-Architektur

Um denAufbauderArchitekturzuverdeutlichenwird nuneinSchichtenmodellvorgestellt,dasdieverschiedenenEbenenmit dendarinverwendetenTechnologiendarstellt.Die vier Hauptschichtender SCA3D-Architektursind, wie in den vorhergehendenKapiteln schonangedeutet,die Web-Schicht,die 3D Visualisierungsschicht, die Dokumentkontrollschicht unddie Bilddatenschicht.InAbbildung7.5ist diesesSchichtenmodellgezeigt.

Im folgendenwerdendieSchichtenundihre interneUmsetzungnaherbeschrieben:

� WWW-Schicht:

Die Web-Schichtwird benutzt,um demBenutzerodereinemAdministratordenZugriff aufden SCA3D-Server und die server-seitigeDatenbankzu ermoglichen.Es werdenHTML-Formulareund server-seitigeCGI-Skriptezur Kontrolle desServers und zum Zugriff auf


Abbildung7.5:AufbauderSCA3D-ArchitekturdargestelltalsSchichtenmodell.

die Datenbankverwendet.Der Benutzerladtzu Beginn die HTML-Start-SeitedesSCA3D-Servers, indemer die entsprechendeURL in seinemBrowseranwahlt. Ein AusschnittderStart-Seiteist in Abbildung7.6gezeigt.Dort sinddieFormular-ButtonszumStartbzw. zumBeendendesServer-ProzessesunddesCORBA-Naming-Serverszuerkennen.DerBenutzerkannsichdurchAuslosendesServer-Status-ButtonsdenaktuellenZustanddesServers,alsodie laufendenProzesseund offeneNetzverbindungenim Browseranzeigenlassen.Das3DDokument,dasbeim Start geladenwird, ist als Bild uber dem Start-ButtondesSCA3D-Serversgezeigt.In diesemFall handeltessichum eindreidimensionalesGebaudemodellimOpenInventor-Format.

Bevor eineVisualisierungssitzungmit SCA3Dstattfindenkann,mußderNaming-Server derMiddleware(CORBA) entwedervoneinemBenutzerodervoneinemAdministratorgestartetwerden.FallsderServer immerzugreifbarseinsoll, wird derNaming-Server aufderServer-Maschinevom AdministratorgestartetundderSCA3D-Server im Anschlußdaranaufgeru-fen. Dannkonnensichdie Benutzerbeliebigan-undabmelden,wahrendderServer-Prozeßund der Naming-Server standigweiterlaufen.Alternativ kannauchder ersteBenutzerdenServer startenund alle weiterenBenutzermussendannlediglich ihren SCA3D-Clientstar-ten.In diesemSzenariokannderersteBenutzersichzu jedemZeitpunktabmelden,ohnedaßdie Visualisierungssitzung der anderenBenutzergestort wird. Ein Skript auf Server-Seitekanndanndafur sorgen,daßbeim AbmeldendesletztenBenutzersder Server-ProzeßundderNaming-Server beendetwerden.

� 3D Visualisierungsschicht:

Diese Schicht dient zur interaktiven Visualisierungder 3D Dokumente,die in den Ser-ver geladenwurden und zum Client verteilt werden.Dafur wird auf Server-Seite undauf Client-Seiteein Szenengraphaufgebautund das OpenInventor-API zum Renderingund zur Interaktionmit den 3D Datenverwendet.DieseSchichtwird durch eine Gruppe


Abbildung7.6:Die GUI-OberflachederWWW-Schicht.QuellederEinzelbilderundModelle:ETHZurich,FachbereichArchitektur.

von Java-Klassengebildet,die uberdasJava-Native-Interface(JNI) auf die OpenInventor-Klassenbibliothekzugreifen,die in C++ programmiertist. Die SchnittstellezwischenJa-va und OpenInventor ist in [WK96] genauerbeschrieben.Die Klassenbibliothekmit demNamen Kahlua ist zum Zeitpunkt der Veroffentlichung dieser Arbeit unter der URLhttp://www.igd.fhg.de/CP/kahlua/index.html verfugbar.

Die Technikenzur 3D VisualisierungundverteiltenSynchronisationwerdenin derVisuali-sierungsschichtderSCA3D-Architekturin dergleichenWeiseangewendet,wie in Abschnitt4.2 beschrieben.Zu denKomponentendieserSchichtgehort auchdasDisplayzur Anzeigeder gerenderten3D Dokumenteauf Client-Seite.DasDisplay und die BedienelementezurInteraktionsind im 3DVis-GUI derClient-Anwendungintegriert. In Abbildung7.7 sinddiegraphischenOberflachenderClient-Anwendung3DVis-GUI unf LoI-PanelalsBeispielge-zeigt,bei demzwei Benutzermit einemCAD-Modell einesGebaudemodellsarbeiten.AufServer-Seitewird eineListemit BenutzernundihrenanwendungsbezogenenDatenverwaltet,dieebenfalls zurVisualisierungsschichtgezahlt wird, allerdingsauchstarkvonderdarunter-liegendenDokumentkontrollschicht benutztwird, dienunbeschriebenwerdensoll.

� Dokumentkontrollschicht:

DieseSchichtdientzurKontrolledeszwischenServerundClientverteilten3D Dokumentes.Dazuwerdenfur aktiveObjekteVerbindungenzwischendemOriginalobjektaufServer-Seiteund der Objektreprasentationauf Client-Seiteuberdie in denvorigenKapitel eingefuhrtenInterface-Objektehergestellt.Die ObjektreprasentationwerdenvomServer alsPfadinforma-tion im OpenInventor-Austauschformat in eineStringvariablegeschriebenunddannalsPa-rametereinesRPCandie Client-Anwendunggesendet.Dort werdensiein die Client-Szeneeingefugt.

Auf Client-SeitewerdenmittelsderPerformanzmessungenundderEinstellungendesLevel-of-Information-Panel die LoI-Datenerzeugt,die ubereinenRPCan denServer ubergeben


Abbildung7.7:Die graphischeOberflache3DVis-GUI derSCA3DClient-Anwendung.QuelledesCAD-Modells:ETH Zurich,FachbereichArchitektur.

werdenund dort bestimmen,welcheObjektreprasentationen fur einenBenutzergeneriertwerden.Fur jedenBenutzerwird auf Server-SeiteeineListe mit denInterface-Objektenundauf Client-Seiteeine Liste mit den entsprechendenObjektreprasentationen verwaltet. DieInterface-Objektewerdenvon derSceneControl-Servant-Klasseerzeugtunduberdieseauchzugegriffen. In Abbildung7.8sindderAufbauunddie ProgrammkomponentenzumEinsatzderDokumentkontrollschicht dargestellt.

Zur RealisierungdieserFunktionenwird die CORBA-ImplementierungJavaIDL derFirmaSunbenutzt,die mit der Java-Umgebung frei erhaltlich ist. DasSceneControl-Interfacede-finiert in derCORBA-eigenenInterface-SpracheIDL dieMethodenschnittstelle zumZugriffaufdieDokumentkontrollobjekte derSoftware-Architektur. EineListener-KlasseaufServer-Seiteund eineSpeaker-Klasseauf Client-Seitesorgenfur die grundlegendeKommunikati-on der SCA3D-Komponentenmit der CORBA-Schicht,die die Middleware-Funktionalitatunddie CORBA-Dienstezur Verfugungstellt. In diesenKlassenwerdenVerbindungenzumjeweiligen ORB (Object-Request-Broker) aufgebautund Objektreferenzenfur die remote-zugreifbarenObjekteerzeugt.ZumEinsatzderServer- undClient-KomponentederSCA3D-Architektur wird zu Beginn ein Name-Server-Prozeßauf einemRechnerin der vernetztenUmgebunggestartet.In derCORBA-Implementierungvon Java ist derName-Server tname-serv.exeenthalten.DenSCA3D-Komponentenwird beimStartmitgeteilt,aufwelchemHost-Rechnerund uberwelchenPort der Name-Servicezuganglich ist. DadurchmussenServerundClientdieAdressengegenseitignichtkennenundeswird diegeforderteOrtstransparenzin derverteiltenArchitekturrealisiert.

� Bilddatenschicht:

DerAufbauderBilddatenschichtwurdeim vorhergehendenKapitelschonnaherbeschrieben.


Abbildung7.8:AufbauundEinsatzderDokumentkontrollschicht.

Daherwird hiernuraufdiezugrundeliegendeTechnologiezurUbertragungeingegangen.Diein der SCA3D-ArchitekturverteiltenBildatenwerdenuberSocket-Verbindungenvom Ser-ver zum Client ubertragen.Dazu werdendie von Java bereitgestelltenBibliotheksklassenSocket undServerSocket verwendet.Die Bildatenwerdenvon derOpenInventorOffScreen-Renderer-Klasseim RGB-Format mit einer einstellbarenAuflosungerzeugtund in einenBildspeichergeschrieben.Aus diesemBuffer werdendie Datenin einenRing-Buffer ge-schrieben,wie es im vorhergehendenKapitel beschriebenwurde.Die BilddatenratekannubereinenOpenInventorTimerSensoreingestelltwerdenundwird entsprechenddenAnfor-derungenderClient-Anwendungengeregelt.

Die Bildaten werdendannvon einemunabhangigenThread-Prozeßausdem Ring-Buffergelesenund uber die Socket-Verbindung zum Client geschrieben.Bevor eine Socket-Verbindungaufgebautwerdenkann, muß der Client sich beim der ServerSocket-Instanz,die auf Benutzeranfragenwartet,ubereinenvorgegebenenPortmelden.Dannwird von derServerSocket-Instanzein mittels ihrer accept-MethodeeineeigeneSocket-Instanzerzeugt,uberdie Server- undClient-AnwendungdieBildatenaustauschen.Damit sicheinClient mitdemServer verbindenkann,mußderClient-Anwendungdie Host-AdresseundderPortbe-kanntsein,auf demder Server horcht.Daherwird demBild-Client der SCA3D-Software-Architektur dieseInformation explizit beim Start mitgeteilt. Da die Host-Adressein denmeistenFallen mit der AdressedesRechnersubereinstimmt,auf dem auchder CORBA-Name-Server lauft, reicht esausdieseAdresseeinmalam Anfangzu ubergeben.Um eineOrtstransparenzfur die Bilddatenschichtzu erreichen,mußtendie Bilddatenebenfalls uberRPC-AufrufealsParameteroderRuckgabewerteausgetauschtwerden.Die VerwendungvonSocket-VerbindungenerlaubtallerdingseinegroßereFlexibilit at beiderBilddatenkommuni-


kation, so daßz.B. Streaming-Methodenbesserrealisiertwerdenkonnen.Daherwird dieUbertragungder Bilddatenuber selbstaufgebauteSocket-Verbindungendem Aufruf vonRemote-MethodenuberMiddlewarevorgezogen.

7.4.2 Umsetzungund Anwendung in einer vernetztenRechnerumgebung

Die HauptkomponentendesProgrammcodessindderSCA3D-Server, derSCA3D-ClientunddasLoI-Panel.Diesewerdenim Komponentendiagrammmit ihren Verbindungenuntereinanderdar-gestellt.DasKomponentendiagrammverwendetalsSymbolfur eineKomponentedrei ineinanderverschachtelteRechtecke. IhreSchnittstellenwerdenalsStrichemit angehangtenKreisengezeich-net.Die AbhangigkeitenwerdenalsgestrichelteLinien dargestellt.

Abbildung7.9:KomponentendiagrammderSoftware-ArchitekturSCA3D.

In Abbildung7.9 ist dasSCA3DKomponentendiagrammgezeigt,dasnebendemServer, demClient und dem LoI-Panel auchdie Schnittstellenverdeutlicht.Die SCA3D-Client-Komponentegreift uberdieCORBA-SchnittstelleaufdenSCA3D-Serverzu,ummit dem3DDokumentarbeitenzu konnen.Umgekehrtexistiert aucheineMiddleware-SchnittstelleamClient, uberdie derServeraktiv Objektreprasentationen in die Client-Szeneeinfugenkann.Die Client-KomponenteenthaltauchdasGraphical-User-Interface, dasim Entwurfskapitelals3DVis-GUI bezeichnetwurde.DieSchieberegler-Komponente(LoI-Panel)ist ebenfalls uberein CORBA-Interfacemit demSCA3D-Clientverbunden.DasGUI mit denSchiebereglernundsonstigenElementenist mit Hilfe derJava-Klassenbibliothekumgesetzt.

In Abbildung 7.10 ist das Deployment-Diagrammfur die SCA3D-Architekturin der obenbeschriebenenEntwicklungsumgebung gezeigt.Die Server- und Client-Komponentensind aufdie zur VerfugungstehendenRechnernverteilt. Der SCA3D-Server lauft dabeiimmer auf einerUnix-Maschine,wahrenddie Client-Anwendungenauf allen Plattformenzum Einsatzkommen.Es soll noch einmal betontwerden,dasauchder SCA3D-Server auf allen anderenPlattformenlauffahigist. Dajedochauchin derPraxisServer-AnwendungenhaufigaufUnix-Maschineneinge-setztwerden,um derenBetriebssicherheitauszunutzen,wird hier dieseKonfigurationvorgezogen.


Abbildung 7.10: Deployment-Diagrammder Software-ArchitekturSCA3D in der Entwicklungs-umgebung.

DasDeployment-Diagrammzeigtauchdie weiterenKomponenten,die nicht direkt zumSCA3D-Systemgehoren.In Abbildung7.10ist diesderCORBA-Name-Server, deraufdemgleichenRech-nerwir derSCA3D-Serverlauft.WeiterhinwerdenauchdieNetzverbindungenzwischendenRech-nerndargestellt.Alle Rechnerarbeitenim IntranetdesInstitutesfur MedienkommunikationIMK.DasIntranetbietetzur KommunikationVerbindungenuberein EthernetundubereineATM-Netzan.Alle KomponentenkommunizierenmittelsdesTCP/IP-Protokolls. Fur Testzweckewurdenver-schiedeneVersionender Software-ArchitekturauchaußerhalbdesIMK-Intranetseingesetzt.DieverwendeteTechnologie(WWW, CORBA, TCP/IP)erlaubtdenallgemeinenEinsatzin heteroge-nenNetzenwie demInternet.

7.5 Zusammenfassung

In diesemKapitelwurdedieImplementierungderSCA3D-Software-Architekturbeschrieben.NachderVorstellungderverwendetenSoftware-WerkzeugeundHardware-Komponentenwurdeeineer-sterPrototyp,dermit MPEG-4VideoobjektendenZugriff auf server-seitige3D Modellerealisier-te, kurz erlautert.DieserPrototypsetztedie IdeedesRemote-Renderingzur verteilteninterakti-ven 3D Visualisierungein. Dabei wurde festgestellt,daßdie Verzogerungszeiten,die durch dieNetzubertragungverursachtwerden,fur eineinteraktive Anwendungim Client-Server-Modell zugroßsind.Als WeiterentwicklungfuhrtdieSCA3D-ArchitektureineKombinationauslokalemundRemote-Renderingein.Die ImplementierungderSoftware-Architekturwurdedannmit Hilfe einesSchichtenmodellsveranschaulichtundderEinsatzin einerrealenUmgebungmit Hilfe von UML-Diagrammenerlautert.DabeiwurdendieRandbedingungenderEntwicklungsumgebungmiteinbe-zogen.ZumAbschlußdesKapitelswurdedieVerwendungvonThreadsin derSoftware-ArchitekturdiskutiertundderZusammenhangzumverwendetenSchichtenmodellaufgezeigt.

Kapitel 8

AdaptiveVisualisierung in OffenenInformationsraumen

Fur die in denvorhergehendenKapiteln beschriebeneSoftware-ArchitekturSCA3D soll hier einAnwendungsszenarioim BereichDigitalerBibliothekenentwickelt werden.Die Funktionalitat derArchitekturim Hinblick aufverteilte3D VisualisierungundaufAdaptivitatdesInformationsgehaltsauf Client-Seitesoll naheruntersuchtwerden.DabeiwerdenalsAnwendungshintergrund offenenInformationsraumeeingefuhrt, die technischeMoglichkeiten zum Umgangmit Komplexitat undSicherheitsanforderungen von 3D Dokumentenbenotigen,um ihren vollen Funktionsumfangpo-tentiellenBenutzernzur Verfugungstellenzu konnen.PraktischeErgebnissewerdendargestellt,diedurchMessungenin derbeschriebenenTestumgebunggewonnenwurden.

8.1 Einf uhrung: Anforderungen in offenenInformationsraumen

VerteiltesArbeitenmit 3D SzenenalsTeil von Multimedia-Dokumentenin vernetztenUmgebun-gensetztdietechnischeUnterstutzungvonMethodenzumRetrieval, zur interaktiverVisualisierungundzurKommunikationvoraus.Ein vernetztesInformationssystemwird hieralsOffenerInforma-tionsraumbezeichnet,wennderZugriff aufDokumenteundDienstenichtaufeinenim vorausfest-gelegtenBereichin einemNetzunddamitauf einenKreis von Benutzerbzw. Informations-Servereingeschrankt ist.

Abbildung8.1:Visualisierungin einemoffenenInformationsraum.

123

KAPITEL 8. ADAPTIVE VISUALISIERUNG IN OFFENENINFORMATIONSRAUMEN 124

WeiterhincharakterisierengleichformigeBedingungenbeim Arbeitenmit digitalenObjektenundSchnittstellenzuanderenInformationsraumeneinenoffenenInformationsraum,dereineMen-gevon Informations-Servern,Dokument-Datenbanken, Benutzernmit ihrenClient-AnwendungenundTelekommunikationsnetzezwischendiesenKomponentenumfaßt.EinesolcherInformations-raummit dreiBenutzern(C), zwei Informations-Servern(S)mit Dokument-Datenbanken(DB) undeinerSchnittstellezwischendenbeidenServernist in Abbildung8.1dargestellt.ZusatzlichkonnenauchlokaleDatenbankenzumVorhaltenvon InformationaufdenClient-Rechnernvorhandensein.

In Abbildung8.1ist außerdemgezeigt,wie einBenutzermit einem3D Dokumentarbeitet,dassichauf einemServer befindetunddurchRetrieval zugreifbargemachtwurde.Die 3D Visualisie-rung desDokumentesauf Client-Seitewird hier durch Kombinationvon Remote-3D-Renderingund lokalem 3D-Renderingrealisiert,wobei dasKonzeptder SkalierbarenSzenenzum Einsatzkommt.DiesesbietetdenVorteil, dasdie Datendes3D Dokumentesin kontrollierbarerFormzumBenutzerubertragenwerdenkonnen.DurchVerwendungeinesobjekt-orientiertenDokumentmo-dellsin FormdesSzenengraphenundeinemDocument-Request-Broker-Ansatzeswird esmoglich,aufentfernteDokumenteundihreObjektemittelsProxy-Objekten,hieralsObjektreprasentationenbezeichnet,in verteiltenUmgebungenzuzugreifen.Durch die Skalierbarkeit desInformationsge-haltsderObjektreprasentationen wird ein adaptivesVerhaltenbezuglich derRandbedingungenderheterogenenUmgebung realisiert.Dies wird im weiterenals Komplexitats-Managementfur ver-teilte 3D Dokumentebezeichnet.Ein Sicherheitsmanagementfur geschutzte3D Dokumentewirdmoglich,daObjekteeinesOriginaldokumentesamServer durchObjektreprasentationenamClientvertretenwerden.Die VerteilungdieserObjektreprasentationenwird andieaktuelleRechtesituationangepaßt.

Der untersuchteAnsatzeinesDocument-Request-Brokers fur verteilteDokumenteermoglichtdie RealisierungderwichtigstenForderungenaneinenoffenenInformationsraum,namlicheiner-seitsdie Schaffung von gleichformigenBedingungenfur denZugriff auf digitaleObjekteunddieBereitstellungvonSchnittstellenzwischenInformationsraumen.DieseEigenschaftenwerdendurchdie einheitlicheDefinition von Schnittstellenzu denDokumentenumgesetzt.Fur denBenutzeristdie Komplexitat der Zugriffe auf die verteiltenDokumentetransparent,d.h. im Idealfall bemerkter keinenUnterschiedzwischenlokalen und entferntenZugriffen (Zugriffstransparenz)und derphysischeOrt einesDokumentesmußdemBenutzerfur einenZugriff nicht explizit bekanntsein(Ortstransparenz).Die Ortstransparenzerlaubtdie Realisierungvon Schnittstellenzwischenver-schiedenenInformations-Servern.Weiterhinist esmoglich,daßmehrereBenutzersichDokumentebeim Zugriff teilen (Concurrency-Transparenz), ohnediesesdirekt zu bemerken. KooperationinoffenenInformationsraumenwird dahervom Document-Broker-Ansatzder SCA3D Architekturals integraleFunktionalitat unterstutzt. Im nachstenAbschnittwird ein AnwendungsszenarioimUmfeldDigitalerBibliothekeneingefuhrt,dasdieEigenschafteneinesoffenenInformationsraumesnutztunddasmit derSoftware-ArchitekturSCA3Din Teilenumgesetztwerdensoll.

8.2 Entwicklung eines Anwendungsszenariosund einer Testumge-bung

AnhandeinesBeispielssoll die Funktionalitat, die demBenutzereinesoffenenInformationsrau-meszurVerfugungsteht,verdeutlichtwerden.Als Beispieldienen3D DokumenteeinervernetztendigitalenBibliothek,die von einerGruppevon StudentenundeinemTutor im RahmeneinesEnt-wicklungsprojektesim BereichArchitektur genutztund erzeugtwerden.Eine digitale BibliothekerlaubtesdenBenutzern,bestehendeDokumentezu erkunden,neueDokumentealsErgebnisder


Gruppenarbeitzuerzeugenundin denDokumentbestandeinzufugen.InnerhalbeinesSystemseinerdigitalenBibliothek solltenaußerdemMoglichkeitenfur verteiltesCut-and-PastemittelsvisuellerMethoden,fur die IndizierungundzurErweiterungvonDokumentenbestehen,d.h.allgemeinver-trauteFunktionalitat im Umgangmit Dokumentensollteunterstutzt werden.

DerSchutzvonOriginaldokumentenunddiekontrollierteVerteilungvonKopienstellenAnfor-derungendar, die bei derEntwicklungeinessolchenSystemsberucksichtigtwerdenmussen.Umdenvollen UmfangderFunktionalitat einesoffenenInformationsraumesnutzenzu konnen,solltedie Arbeit mit Dokumentensowohl in einemlokalenNetzmit eventuellspezialisierterAusrustung(Instituts LAN), als auch von zuhauseaus mit einem Notebook-Computeruber eine Modem-Verbindungmoglich sein. Die Uneinheitlichkeit bezuglich der Netzanbindungbzw. der lokalenLeistungsfahigkeit der verwendetenRechnerund die Beschrankungenbezuglich bestehenderSi-cherheitsanforderung, wie Copyright oderVertraulichkeitsschutz, solltenbeimEntwurfeinerunter-liegendenSoftware-Architekturvon Beginn anberucksichtigtundentsprechendeLosungenin dasKonzeptintegriertwerden,wie esbeiderSCA3DArchitekturgeschehenist.

Die PhasenwahrendeinerArbeitssitzung,bei der ein BenutzerubereineSCA3D-ClientaufseinemRechnermit einementferntenSCA3D-Server kommuniziert,sind im folgendenbeschrie-ben.Bei derAusfuhrungtretenmanchePhaseneventuellmehrfachauf,wie z.B.dieEvaluationderRandbedingungen,die periodischwiederholtwerdenmuß,da sich die Anbindungund die lokaleBelastungim LaufederZeit andernkann.AnderePhasen,diein variablerReihenfolgewiederholbarsind,wie z.B. dasAbspeichernvon verandertenDokumenten,werdenin derfolgendenAuflistungmit demAttribut wiederholtgekennzeichnet.

� Anmelden: Ein BenutzermeldetsichzuerstbeimWWW-Server derWWW-Schichtan.DieAbfrageeinesPaßwortesundPaßwortschutzwird vomHTTP-Protokoll unterstutzt.WenneinBenutzernochkeinenZugangbesitzt,wird ihm ein entsprechendesKennwort mit Paßwortzugeordnet.EinemBenutzerist immerein bestimmterBenutzertyp(User-Type) zugeordnet.In demhier beschriebenenSzenariogibt esGaste,Mitglieder, Administratoren,Besitzerei-nesDokumentesundIndividuen,d.h.Benutzer, dieeineneigenenBenutzertypdarstellen.DieZuordnungderRechteist unterdemPunktRechteverhandlungbeschrieben.Die zugehorigeInformationkannam Server in einerDatei oder in einerDatenbankabgelegt werden.DerSCA3D-Client-Anwendungwird dieAccount-InformationzurAuthentifizierungvomBenut-zer mitgeteilt,entwederdurchTexteingabein ein EingabefensteroderdurchBereitstellungeinerDatei,aufdiederClientzugreifenkann.

� Retrieval: DamiteinBenutzermit einerDigitalenBibliothekarbeitenkann,mussenMoglich-keitenzumRetrieval in derserver-seitigenDatenbankexistieren.Die SuchenachDokumen-ten kann metadaten-basiertoder inhaltsbasierterfolgen.Beim metadaten-basiertenRetrie-val werdenzusatzlicheDatenzu einemDokumentdurchsucht,die in der Datenbankabge-legt wurden,um ein der AnfrageentsprechendesDokumentzugreifbarzu machen.Bei derinhalts-basiertenSuchewerdenvorherextrahierteMerkmaleder Dokumentdaten,wie z.B.Farbhistogrammebei Bildern,benutzt,um inhaltlicheUbereinstimmungenzwischenAnfra-geundDokumentzufinden.WahrendderEntwicklungderSCA3D-ArchitekturwurdeaucheineTechnikzum inhalts-basiertenSuchenvon 3D Modellenin relationalenDatenbankenentwickelt undumgesetzt.Die TechnikundeinSystemist in [Loe00b] beschrieben.Die Aus-gabedesRetrievalprozessesist eineHTML-Seitemit einerAuflistungvon 3D Dokumenten,die aucheineDarstellungalsgerendertesBild enthalt. PraktischeErgebnissedesRetrievalsmit dervorgestelltenTechniksindebenfalls in [Loe00b] beschrieben,


� AuswahleinesDokumentes: Der Benutzerkannnun durchAuswahl einesder gefundenenDokumente,diesesDokumentin denSCA3D-Server ladenund mit der interaktiven Visua-lisierungbeginnen.DasausgewahlteDokumentwird dazuinnerhalbeinerHTML-Seite,dieauchdie notigenKontrollelementefur denSCA3D-Server enthalt, demBenutzerangezeigt,indemderstrukturelleAufbauwiedergegebenwird (siehez.B. Abbildung2.2).

� LadendesDokumentesin denSCA3DServer: DurchAuslosendesStart-Buttons, dereinemDokumentzugeordnetist,wird derSCA3D-ServergestartetunddasDokumentin denServergeladen.Falls der Server schonlief, wird dasDokumentin denlaufendenServer geladen.DerBenutzerstartetnunlokal denSCA3D-Client,dersichmit demSerververbindetunddieverteilteVisualisierungssitzungeinleitet.Zunachstist das3D DokumentdemBenutzernuralsBildreprasentation,d.h.uberRemote-Rendering-Methoden, zuganglich.

� Evaluationder Randbedingungen (periodisch): Sobalddie VerbindungzwischenServer undClient aufgenommenist, wird mit der Grundkonfigurationder Client-Szenedie erstePer-formanzauswertungvorgenommen,wie sie in Abschnitt5.8beschriebenwurde.DabeiwirddasoptimaleVerhaltniszwischenlokaler(LFR) undRemote-Framerate(RFR)bestimmtundentsprechendeingestellt.Nacheiner festgelegten Zeitspannewird dieseEinstellungdurchMessungderLFR- undRFR-Werteuberpruft. FallsdasoptimaleVerhaltniszwischenlokalerund Remote-Frameratenicht mehrerreichtwird, mußeineneueEinstellungdurcheineer-neutePerformanzmessungermitteltwerden.DieseneueEinstellungist dannoptimalandieRandbedingungen,wie AnbindungundlokaleLast,angepaßt.

� Aushandlungund Vergleich der Rechte (wiederholt): Beim LadendesDokumentesin denSCA3D-Server werdendie entsprechendenIPR-Informationenin denSzenengraphals Zu-standeinesEigenschaftsknotensintegriert. Bei derAktivierungeinesObjekteswird die Be-nutzerinformation,die mit dem Remote-Document-Call(RDC) ubertragenwird, am Ser-ver mit der IPR-Informationder aktivierten Objektgruppeverglichen.Die entscheidendenInformationenzur Erzeugungeiner Objektreprasentationsind die sogenannteDocument-Distribution-Class (DDC, vgl. Abschnitt 2.4.4) und die Auflosung � , die in der IPR-Informationfestgelegt sind.Die Benutzerinformationenthalt ebenfalls eineDDC undeinenWert fur die Auflosung,die durchdenBenutzertypbestimmtwerden(z.B. Gast: ø¹øµä��äNú�è§ç¢ç�� , ��cú�ò�� ). DieseInformationengebendieobereGrenzederDDCundderAuflosungan,die bei der Erzeugungder Objektreprasentationeingehaltenwerdenmuß(z.B. ein Gastkann keine ClassC-Objekteerhalten).Weiterhin gibt die Benutzerinformationden aktuel-lenLevel-of-InformationderClient-Anwendungan,derebenfalls durchdiebeidenAngabenDDC undAuflosungbeschriebenwird.

MochteeinBenutzerindividuelleRechteerwerben,umz.B.alsGasteinenhohereAuflosungeinesObjekteszu erhalten,so mußdiesverhandeltwerden.Es warez.B. denkbar, daßeinDokumentbeiAngabeeinigerAdreßangabendesBenutzersmit hohererAuflosungerhaltlichist. Zum ErwerbeinesOriginaldokumentesmußteeinesichereZahlungsmethodeintegriertwerden.DieserPunktsoll jedochhier nicht weiter untersuchtwerden.In demvorgestelltePlanungsprojektim ArchitekturbereichkannvielmehreinebestimmteGruppevonBenutzernfestgelegt werden,die automatischZugriff auf alle OriginalederDokumentehaben,die sieselbsterzeugtundin dieDigitaleBibliothekintegrierthaben.GenausosindnurdieserGruppeSchreibrechtezugewiesen,sodaßsieDokumentein dieDatenbankeinfugenkonnen.

� Interaktionmit Objekten(wiederholt): DerBenutzerhatverschiedeneMoglichkeitenmit den


Dokumentenzuarbeiten.Die Visualisierungkannbeeinflußtwerden,durchVeranderungderBeleuchtungoderderKameraparameter. Objektekonnenverschoben,rotiertundskaliertwer-den.Mit hoherwertigenMethodenkannaucheineModellierung,z.B. von parametrisiertenOberflachen,erreichtwerden.Dabeiwird immer mit der lokalenObjektreprasentationalsProxy-Objektgearbeitet.Auch neueObjektesollenin das3D Dokumenteingefugt werdenkonnen.Dieswird durchzusatzlichesLadenvonDokumentenerreicht.

� AbspeicherungdesneuenDokumentesin derDL undeinerlokalenKopie(wiederholt): NachderBearbeitungkonnenDokumentein dieDatenbankeingefugtwerdenundeventuelllokaleKopien desclient-seitigen3D Dokumenteslokal abgespeichertwerden.Hat der BenutzereineOriginal erworben,so wird diesesausder Server-Datenbankgeloschtund vollstandigaufdemBenutzerrechnerabgelegt.

� SchließeneinesDokumentes(wiederholt): Nach der Beendigungaller Bearbeitungs-undSpeicherschrittekanndas3D Dokumentgeschlossenwerden,indemderDokumentszenen-grapham Server und am Client geloschtwird. Danachkannein neuesDokumentgeladenwerden.

� Abmelden: Wenndie Visualisierungssitzung beendetwerdensoll, meldetsich der BenutzeramServer abundschließtseineClient-Anwendung.Die Benutzer-Informationwird amSer-ver verwaltetundbeimnachstenAnmeldendiesesBenutzerswiederverwendet.

Im denfolgendenAbschnittenwerdendie PunkteKomplexitatsmanagementund Sicherheits-managementanhanddiesesAnwendungsszenariosnaheruntersuchtundpraktischeErgebnissevor-gestellt.

8.3 Komplexitats-Managementfur verteilte 3D Dokumente

In diesemAbschnitt wird eine Losungzum Umgangmit Komplexitat von 3D DokumentenindemskizziertenAnwendungsszenariounterVerwendungderSCA3D-Architekturbesprochen.Da-zuwerdenfur verteilteDokumenteundfur Benutzerbzw. ihreClient-AnwendungenInformationenfestgelegt, dieeineKlassifizierungundaufdieseWeiseeinesinnvolle SteuerungderDokumentver-teilungerlauben.Ein Dokumentwird hier durchseinenInformationsgehaltundseineDatenmengebeschrieben.Client-AnwendungenwerdenKlassenzugeordnet,die ihrengemessenenlokalenundRemote-Frameratenentsprechen.Im folgendenAbschnittwird danndieseInformationmit Hilfevon Document-Distribution-Klassenfur ein Sicherheitsmanagementerweitert,um denSchutzvongeistigenEigentumsrechtenundderVertraulichkeit von Daten(Copyright, vertraulicheProduktda-ten,etc.)zugewahrleisten.

8.3.1 Klassifizierung von 3D Dokumentenbezuglich desInformationsgehaltes

Zur Beschreibung desInformationsgehaltes eines3D Dokumenteswird seineReprasentationformunddiejeweiligeAuflosungverwendet.DerEinfachheithalberwerdendieObjektreprasentationen,dievonSCA3Dunterstutzt werden,durchfolgendenAbkurzungengekennzeichnet:÷�� : parametri-scheModelle, ÷�� : polygonaleNetze, ÷�� : Bounding-Box,÷! : Bilddaten.Der Informationsgehaltwird dadurchbestimmt,wieviel Informationuberdas3D Dokumentder Benutzerdurchdie Re-prasentationformgewinnenkann.ParametrischeModellebesitzendaherhier dengroßtenInforma-tionsgehaltundBilddatendengeringsten.


DieAuflosungwird entsprechendderjeweiligenReprasentationformangegeben.Alsoz.B.mitt-lereMaschengroßebei 3D-Netzenoderbei Bildern Bildpunktepro Langeneinheit(dpi). Bei para-metrisiertenModellenwird davon ausgegangen,daßdie Parametervollstandigubertragenwerden.Wennder Client alsodasBasiswerkzeugzur ErzeugungeinessolchenObjekteskennt,hat er mitder Angabeder Parameterdie Moglichkeit, dasObjektbeliebiggenaudarzustellenund zu repro-duzieren.Fur ein parametrischdargestelltes3D Objektwird hier dahernur ein moglicherWert furden Informationsgehaltangenommen.Im Fall von 3D-Netzenhat ein Objekt mit einer hoherenAuflosungeinenhoherenInformationsgehaltalsein Objektmit geringererAuflosung.Dabeiwer-denkeinenumerischenWertefur denInformationsgehaltverwendet,sonderndiebeidengetrenntenAngabenderKennung( ÷�� - ÷! ) undderAuflosung( �#" ) zumVergleichbenutzt.

Bei derVerteilungvon 3D Dokumentenist nicht nur der Informationsgehaltwichtig, sondernbesondersauchdie damit verbundeneDatenmenge,die ubertragenwerdenmuß.Ein 3D Objekt,dasvon einerVisualisierungsanwendung dargestelltwird, kannauf demBenutzerdisplaymit dergleichenAuflosungerscheinen,alsodiegleicheRechenkapazitat in Anspruchnehmen,obwohl dievorherubertrageneDatenmengesehrunterschiedlichist.DaauchparametrischeObjektebeiderVi-sualisierungin 3D-Netzemit einerbestimmtenAuflosungumgewandeltwerden,ist die Reprasen-tationformin diesemFall hauptsachlichentscheidendfur die Ubertragung.ParametrischeModellesind aufgrundihrer meist geringerenDatenmenge,die ubertragenwerdenmuß,oft von Vorteil,wenneineschwacheNetzanbindungvorliegt. Allerdings liegenviele 3D Modellevon vornhereinals3D-Netzvor, lassensichnichteinfachin parametrisierterFormdarstellenodersollenebennichtmit vollen Informationsgehaltubertragenwerden,sodaßdieserVorteil nicht immernutzbarist.

Abbildung8.2:AuswahleinergeeignetenReprasentationsform.

Die Datenmengeeines3D Dokumentesist im Fallevon3D-NetzenproportionalzurAnzahlderDreiecke, mit denendie Oberflachemodelliertist. Aus derAnzahlderPolygonemultipliziert mitdemSpeicherbedarfpro Polygonkanndie Datenmengeungefahrberechnetwerden,wobeizusatz-liche Information,wie Materialparameteroder Metadaten,nicht erfaßt werden.Die Anzahl derPolygonehangt von der Auflosungund von der Großeder Oberflacheab. Die Auflosungist inAnzahl von Dreiecken pro Flacheneinheitgegeben.Wennein Benutzerein 3D Objekt selektiert,


werdendie wichtigstenMetadaten,wie Reprasentationsform÷%$ , benotigte Anzahl der Dreieckebei derDarstellung,DatenmengeundOberflacheermittelt.Dannwird eineAbschatzungderglei-chenMetadatenfur diesesObjektin eineranderenReprasentationsformvorgenommen.DurchdenVergleichderBedingungenderLeistungsklasse(L-Klasse), diederClient-AnwendungbeiderPer-formanzmessungzugeordnetwurde,wird diepassendeObjektreprasentationausgewahlt.

In Abbildung8.2 ist der Prozeßder Auswahl einergeeignetenReprasentationsformeines3DDokumentesfur einebestimmteL-Klassegezeigt.Die Reprasentationsform,die AnzahlderPoly-goneunddie GesamtoberflachedesOriginaldokumenteswird bestimmt,die beidenletzterenWer-te in der Regel naherungsweise.Dannwird ein Abschatzungder gleichenDatenfur die in Fra-gekommendenReprasentationformenvorgenommen.Im Fall von 3D-Netzenwird eineminimaleAuflosung�'& $)( gefordert,um ein Ubergangskriteriumzur nachstniedrigerenReprasentationformfestzulegen.Eswird angenommen,daßunterhalbvon � & $*( , derInformationsgehaltgegenubereinerBounding-Box-Reprasentation nicht wesentlichbesserist. Die obereGrenzeder Auflosung �'&,+.-wird durchdie maximaleAnzahlvon Dreiecken bestimmt,die durchdie LeistungsklassederBe-nutzeranwendungfestgelegt wird. Mit Hilfe dieserGrenzenwird diepassendeObjektreprasentationfur dasselektierteObjektund die aufrufendeClient-Anwendungermittelt. In gezeigtenFall wirddie Bounding-Box-Information desObjektesubertragen( ÷�� ), daeine3D-Netzmit der geforder-ten Auflosungeinezu großeMengean Polygonenenthaltenwurdeund daherderClient zu starkbelastetwurde.Im nachstenAbschnittwerdendiesogenanntenL-Klassennahervorgestellt.

8.3.2 Einordnung von Client-Anwendungenin Leistungsklassen

Die Client-Anwendungenwerdenentsprechendder beim PerformanztestgemessenenWertevonlokalerundRemote-Frameratein vier Klassen(L-Klassen)eingeteilt,dievier Quadrantenim LFR-RFR-Diagrammentsprechen(sieheAbbildung8.3).JederL-KlassewerdendannObjektreprasen-tationenmit bestimmtenInformationsgehaltenzugeordnet,wobeieinevorgenommeneZuordnungsichim VerlaufdesArbeitsprozessesalssinnvoll herausstellenmuß.

Automatischwird nuneinBereichdesSchiebereglersmarkiert,innerhalbdessendieBedingun-genderLeistungsklasseerfullt werden.DerBenutzerkanndanndurchEinstellunginnerhalbdiesesBereicheseineReglerpositionwahlenund dasselektierteObjekt anfordern,dasdannubertragenund in die Client-Szeneeingefugt wird. Ein Benutzerkannaberauchvon diesenEmpfehlungenabweichenund eineanderenReprasentationsformwahlen,solangeer nicht die Sicherheitsbedin-gungenverletzt,diespaterbeschriebenwerden.

In Abbildung8.3 ist einemoglicheKonfigurationderL-Klassenim LFR-RFR-DiagrammfureineAnwendungsszenariodargestellt.DieseKonfigurationist durcheinenmaximalenWert fur dieAnzahlderPolygonepro selektiertesObjektunddie gefordertenFrameratenderBenutzeranwen-dungangegeben.Die Grenzen�0/N÷!1 Frames/sund ÷�/N÷!1 Frames/slegendie vier in Abbildung8.3 verwendetenL-Klassenfest.Die GrenzensinddabeialsErfahrungswerteausdenMessungenin derTestumgebung entstanden.Client-AnwendungenwerdennacheinemPerformanztest,in ei-nedervier Klasseneingeordnet.Die BedingungenderKlassewerdendannfur die ZuteilungvonObjektreprasentationen benutzt.

8.3.3 Realisierungmittels der OpenInventor-KlasseSoComplexity

Im folgendensoll eineRealisierungfur eineneingeschranktenAnwendungsfall beschriebenundinnerhalbderSCA3D-Architekturgetestetwerden.Die Einschrankungbestehtdarin,daßausOri-ginaldokumentennur geometrischeBasisobjekte(Sphere-,Cube-,Cone-Objekt,NURBS-Flachen,


Abbildung8.3:EinteilungdesLFR-RFR-Diagrammsin Leistungsklassen.

etc.),diesichim OpenInventor-Formatparametrischdarstellenlassen,mit skalierbaremInformati-onsgehaltaktiviert werdenkonnen.3D-NetzeinnerhalbdesOriginaldokumenteswerdenentwederwiederals3D-Netzemit dergleichenAuflosungaktiviert oderkonnenalsBounding-Box-Reprasen-tationin die Client-Szeneeingefugt werden.Weiterhinwerdenhier nur Ubergangevon parametri-schenReprasentationsformen( ÷�� ) zu3D-Netzen( ÷�� ) oderzuBounding-Box-Reprasentation ( ÷�� )naheruntersucht.Das Originalobjektliegt alsoals ÷�� -Objekt vor und wird bei der Aktivierungentwederin ein Dreiecksnetzmit geeigneterAuflosungoderalternativ in eine ÷�� -Reprasentationumgewandelt.Mit diesenEinschrankungenlassensichtrotzdemdiewichtigstenEigenschaftenundMethodendesKomplexitatsmanagementsderSCA3D-Architekturuntersuchen,wobeigleichzeitigdieentscheidendenKonzepteklarerherauskommen.

Eine Moglichkeit dasbeschriebeneKomplexitatsmanagementmit OpenInventor umzusetzen,ist die Verwendungder KlasseSoComplexity. DieseKlasse,derenInstanzenals Knoten in denSzenengrapheingebundenwerden,erlaubtdie Steuerungder AuflosungdesDreiecksnetzes,dasbei derDarstellungvon parametrischenObjektenverwendetwird. Z.B. werdenauchBasisobjektewie eine Kugel oder ein Konus,die im OpenInventor-Format durch die ParameterRadiusbzw.Grundradiusund Hoheangegebenwerden,vor der Darstellungauf demBildschirm in 3D-Netzeumgewandeltundweiterverarbeitet.Die Auflosungist normalerweisemit einemKomplexitatswertvon ä2�3�5476 verknupft. IndemnuneinComplexity-Knotenvor dasbetreffendeObjektim Szenen-graphenplaziertunddemKomplexitatswerteineZahlzwischen6476 und �5476 zugewiesenwird, kanndieAuflosungdieses3D-Netzesschrittweisereguliertwerden.

Der ZusammenhangzwischenKomplexitatswertund Anzahl der Dreiecke ist fur verschiede-neObjekteunterschiedlich.EineKugelwird z.B.bei einemmaximalenKomplexitatswertmit sehrviel mehrDreieckendargestelltalsein Konus.DieserZusammenhangist fur OpenInventorKugel-und Konus-Objektegemessenwordenund in Abbildung 8.4 dargestellt.Es ist anzumerken, daßdie Anzahlder Dreiecke pro Objektnicht von der Großeder Objekteabhangt,d.h. bei einemfe-


Abbildung8.4: ZusammenhangzwischenComplexity-Wert und Dreiecksanzahlfur verschiedeneOpenInventor-Objekte.

stenKomplexitatswertwird ein Kugelobjektmit dem Radius ë8�9�5476 mit der gleichenAnzahlvon Dreiecken dargestellt,wie eineKugel mit demRadius ë:�;�#6476 . Darausfolgt, daßmit derSoComplexity-KlassenichtdirektdieAuflosungbeliebigerObjektekontrolliertwerdenkann,son-dernesmußjeweils eineUmrechnungzwischenKomplexitatswertund Auflosungmit Hilfe derAngabenuberObjekttypundOberflachevorgenommenwerden.Die ErmittlungvonKomplexitats-werten,die zu einerAuflosungeinesObjektesgehoren,ist graphischebenfalls in Abbildung 8.4gezeigt.Um denKomplexitatswertzu ermitteln,wird die geforderteAuflosung< mit demOber-flachenwertmultipliziert unddamitdie GesamtanzahlderDreiecke des3D-Netzesberechnet.Derzugehorige Komplexitatswert ä,=?>A@+CBED�FEGCH kanndannanhandderKurve abgelesenwerden.Die ma-ximale Anzahl von Dreiecken pro Objekt, die einerL-Klasseentspricht,kanndirekt demKom-plexitatswert ä &,+.- zugeordnetwerden.In derSoftware-ArchitekturSCA3Dwird die ZuordnungderKomplexitatswertezu derDreiecksanzahlfur verschiedeneObjektealsParameterlistebekanntgemacht.

In Abbildung8.6sindObjektreprasentationeneinerparametrischenOberflachegezeigt,diebeider Aktivierung in den InteraktionsraumdesBenutzerseingefugt wurden.Es handeltsich dabeium Dreiecksnetzemit steigendemKomplexitatswertzwischenù!�I64J� und ù��I64LK . AußerdemistnochdasOriginalobjektals NURBS-Flacheim Interaktionsraumgezeigt.Um fur ein 3D Objekt,dasvoneinemBenutzeraktiviert wird, eineObjektreprasentationals3D-Netzmit einerbestimmtenAuflosungzu erzeugen,wird in die GruppedesselektiertenObjektes,die alsKopie im Interface-Objektvorliegt, ein SoComplexity-Knoteneingefugt undderKomplexitatswertsoeingestellt,dasbei der Erzeugungdes3D-Netzesdie passendeAuflosungerzielt wird. Das3D-NetzselbstwirddurchAbtastendesOriginalobjektesbeimAufruf einesOpenInventor-SoTriangleCB erzeugt,wobeidieEckpunktkoordinatenderAbtastpunktegespeichertwerden.DieseEckpunktewerdendannz.B.mit Hilfe von SoTriangleStripSetin ein zusammenhangendesDreiecksnetzeingefugt. Die Metho-dendesInterface-Objektes,die zumAufruf desSoTriangleCBbenotigt werden,sindin Abbildung8.5alsJava-Quelltext gezeigt.


Abbildung8.5:Quelltext derMethodenzumAbtasteneines3D Objektes.

Um Kriterien fur die Ubergangevon einerObjektreprasentationin eineanderezu finden,wer-dennebendenBedingungenausdenL-Klassender Client-AnwendungennochweitereAngabenuberdie einzelnenLevel-of-Informationbenotigt. DasZiel ist die Zuordnungvon Objektreprasen-tationmit verschiedenenAuflosungenaufdiegesamteLoI-Skala,wie in Abbildung8.7dargestellt.Um dieseZuordnungfur dieObjektreprasentationen ÷�� bis ÷�� vorzunehmen,werdendieobenbe-schriebenenKomplexitatswerteverwendet.Am oberenEndederLoI-Skalabefindensichdie para-metrischenObjektreprasentationen, diebeiderVisualisierungmit einemKomplexitatswertä2�M�5476verarbeitetwerden.Dannfolgen die 3D-Netzreprasentationen,die KomplexitatswertenzwischenäN�O�5476 und äP��64J� zugeordnetwerden.Sowohl parametrische,als auch3D-Netzreprasenta-tionenkonnenalsodenKomplexitatswertä3�Q�5476 besitzen.Die Bounding-Box-Reprasentationen( ÷�� ), diealsnachstesfolgen,werdenmit demKomplexitatswertä2�R6476 verknupft.

Im Falle von 3D-Netzenwird eineMindestauflosungvon < & $*(S� � T=?>A@+UBED�F ( F $*( D�F $*V festgelegt,um ein Kriterien fur die Ubergangevon ÷�� nach ÷�� zu erhalten.Aus dieserBedingungund dermaximalenAnzahl von Dreiecken pro Objekt der L-Klassenergebensich minimale und maxi-maleKomplexitatswerteäW& $*( und äW&,+.- , die denBereichder optimalenLoI-Positionenfur eineClient-Anwendungmarkieren.Fur ÷�� -Reprasentationengilt ä & $*(S��ä &W+C- �X�5476 , d.h.wennei-neClient-AnwendungdiemaximaleAuflosung,mit dereineparametrischeObjektangezeigtwird,nicht mit denBedingungender L-Klassevereinbarenkann,wird ein Ubergangvon ÷�� nach ÷��vorgenommen.

Wennein Benutzernun mit einementfernten3D DokumenteinerdigitalenBibliothek arbei-tet, werdenbei derSelektioneinesObjekteszwei Bereicheauf derSkaladesLoI-Reglersmakiert(sieheAbbildung 8.7). Einerseitswird der optimaleBereichfur die Komplexitat von Objektre-prasentationenin grunerFarbegekennzeichnetunddieLoI-Positionautomatischin diesemBereicheingestellt.Zum anderenwird eineBereichrot markiert,deranzeigt,welcheObjektreprasentatio-


Abbildung8.6:ReprasentationeneinerNURBS-Flacheals3D Netzmit steigederKomplexitat undalsOriginal.QuelledesModells:Teapotim OriginalvonM.Newell.

nenausGrundenfehlenderRechtenichtubertragenwerdendurfen.Die PositionendiesesBereichessindfur denBenutzergesperrt.

8.3.4 PraktischeErgebnissezum adaptivenVerhalten von SCA3D

In diesemAbschnittsollenErgebnisseim Bezugaufdasadaptive VerhaltenvonSCA3D,die in derTestumgebung gewonnenwurden,vorgestelltund diskutiert werden.Zuerstwird die Leistungs-bewertungund dasdynamischeVerhaltenvon Client-Anwendungenbezuglich der lokalen undRemote-Frameratennaheruntersucht.Die Zuordnungvon L-Klassenzu Client-Rechnernin derTestumgebung,dieAnpassungderFrameratenunddiewiederholteAuswertungdurchPerformanz-testswird hierbeschrieben.Danachfolgt einUnterabschnitt,in demdasKomplexitatsmanagementanhandvon MessungenwahrenddesArbeitsprozesseserlautertwird. WeitereErgebnissezumad-aptivenVerhaltendesSCA3D-Architektursindauchin [LFe01]vorgestellt.

DynamischesVerhalten von Client-Anwendungenim LFR-RFR-Diagramm

Anhandvon Messungenmit drei Testrechnernsoll eineZuordnungvon L-Klassenvorgenommenunddie BewertunganhandderPerformanzmetrikausKapitel 5 dargestelltwerden.Damit bei sich


Abbildung 8.7: VerwendungdesComplexity-Werteszur Einteilung der LoI-Skala ( < & $*(Y�Z�#6Dreiecke proFlacheneinheit).

anderndenBedingungenim Hinblick auf die Anbindungsbandbreiteunddie lokaleBelastungeineAnpassungderverteilten3D Visualisierungerfolgenkann,mussendieRaten,mit denenamServerBilder gesendetwerdenundamClient alsTextur abgebildetwerden,wahrenddesArbeitensange-paßtwerden.Diesgeschiehtmit Hilfe der im Performanztestbestimmten�W/N÷ - ÷�/N÷ -Kurve, diecharakteristischfur einenClient-RechnerunterdenvorliegendenBedingungenist. WennsichdieBedingungenuberein festgelegtesMaßhinausverandern,wird eineneueAuswertungderaktuel-len Performanzvorgenommen,um eineneueCharakteristikzu erhalten.DieseSchrittewerdenimFolgendennaheruntersucht:

� Zuordnungvon L-Klassen: Die Testrechnersind ein Windows-Notebook,ein Windows-PCund eine Unix-Workstation,mit den Eigenschaftenwie sie in Abbildung 7.3 beschriebenwurden.Fur alle drei Rechnerwurdemit derGrundkonfigurationderClient-SzeneeinePer-formanzauswertungvorgenommenund ein optimalesVerhaltnis von lokaler und Remote-Frameratebestimmt.Diese optimalenPunktesind in Abbildung 8.8 durch die Vektorenvom UrsprungdesLFR-RFR-Diagrammszum Koordinatenpunktó��W/N÷\[�÷�/N÷rô�]�^#V darge-stellt. Zur Einordnungvon Client-Rechnernin L-Klassenwurden die Werte fur �0/N÷!1( _5/NëEè%ì�æ�ç5Èç ) und ÷�/r÷a1 ( �#/£ëtè%ì�æ�ç5Èç ) festgelegt. DieseWertewurdenhier so gewahlt,daßin den Klassen �b� (Windows-Notebook),�,� (Unix-Workstation)und �c (Windows-PC) jeweils ein Reprasentantvorhandenwar. Die ermitteltenWertefur lokaleundRemote-FrameratendereinzelnenClient-Rechnersindin Abbildung8.12aufgelistet.

� AnpassungvonServer-FramerateundTexture-Mapping-Rate

DurchVeranderungderverfugbarenBandbreitebzw. der lokalenLast,hervorgerufendurcheine Erweiterungder Client-Szeneoder durch andereProzesseauf dem Rechner, werdensichdie Werteder lokalenundRemote-FrameratenwahrenddesArbeitsprozessesebenfallsandern.DamitdasverteilteSystemdynamischaufdieseAnderungenreagierenkann,mussendieBilderzeugungsratenamServer ( ãd/N÷ ) unddie lokaleTexture-Mapping-Rate( våe÷ ) andie neuenBedingungenangepaßtwerden.Dafur werdenin der SCA3D-Architektur, nach-


Abbildung8.8:KlassifizierungderTestrechner.

demeinePerformanztestausgefuhrt wurde,die lokaleundRemote-Frameratein regelmaßi-gen Abstandengemessenund anhandder �0/N÷ - ÷�/N÷ -Kurve eine Anpassungvon �åI÷und ãe/N÷ vorgenommen.Dabei wird ausdem �0/r÷ - ÷�/N÷ -Diagramm,dasdurch schritt-weiseErhohungder Texture-Mapping-Ratewahrendder Messungentstandenist, der ent-sprechendeWert fur dieTexture-Mapping-RatealsParameterbestimmt.Die entsprechendenMeßwerteundder våe÷ -Parameterwerdendafur interngespeichertundsind fur die letztePerformanzmessungzugreifbar. Die Server-Framerateãd/N÷ wird dannuberdasCORBA-InterfaceentsprechenddemWert von våI÷ automatischangepaßt,wobeidie beidenWertehier gleichgesetztwerden.Wennmehralsein Client versorgt werdenmuß,wird die Server-Framerateandie maximaleTexture-Mapping-RateangepaßtunddieFullratenderim ServerintegriertenBild-Buffer fur dieanderenClient-Anwendungenentsprechendreguliert.

� WiederholteAuswertungderPerformanz

Wenndie BandbreiteundlokaleLastzu starkvon denBedingungenabweicht,die wahrenddesPerformanztestsvorgeherrschthaben,dannwird eineerneuteAuswertungder Perfor-manz veranlaßt.Um ein Kriterium fur die Wiederholungzu finden, wird wiederumdas�W/N÷ - ÷�/N÷ -Diagrammherangezogen,wie in Abbildung 8.9 fur einenTestrechnerdarge-stellt.Dafur wird dieSteigungder �0/r÷ - ÷�/N÷ -Kurvesoausgewertet,daßeinBereich(grunerBereichin Abbildung8.9(rechts))bestimmtwird, in demdieSteigungandenausgewertetenPunktennochnicht unter �56gf desmaximalenWertesgesunken ist. DieserBereichwird aufBereichefur �W/N÷ und ÷�/N÷ abgebildet,die in Abbildung8.9(links) ebenfallsgrunmarkiertsind.InnerhalbdieserBereichebehalt diePerformanzmessungihreGultigkeit, wahrendeineerneuteAuswertungnotig wird, wenndie Werteder FrameratenaußerhalbdieserBereicheliegen.Dies ist in Abbildung8.9 (links) ebenfalls angemerkt.Die dargestelltenKurvensind


durchInterpolationderMeßwertemit demProgrammGnuplotentstanden.

Abbildung 8.9: BestimmungeinesstabilenBereichesfur die Leistungsbewertung von Client 1(Win-Notebook).

Die beschriebeneAuswertungderPerformanzist fur die anderenbeidenRechnerderTest/-umgebungin denAbbildungen8.10und8.11dargestellt.Esist zuerkennen,daßdieoptima-lenEinstellungenfur dieFrameratenzwischendenRechnernvariieren.Der typischeVerlaufder �0/N÷ - ÷�/N÷ -Kurven mit einermaximalenSteigungund einerAbflachungin denauße-ren Bereichenist jedochbei allen Testrechnernzu beobachten.DieserVerlauf kanndurchdie LeistungsgrenzedesServersbei derBilderzeugungbzw. -ubertragungunddie maximalelokale FramerateohneTexture-Mappingerklart werden.Im Bereichrelativ hoherRemote-Frameratenwird auchbei weitererSteigerungvon TMR undSFRkeineErhohungderRateerzielt,mit der Texturenubertragenund angezeigtwerden.Daherkannder Client-RechnereinekonstanteArbeitsmengefur daslokale3D-Renderingverwenden,wodurchsichdieAb-flachungamrechtenRandder �0/N÷ - ÷�/r÷ -Kurveergibt.Fur sehrgeringeBildratenvomSer-ver, mußdieClient-AnwendungeineverschwindendgeringeArbeitsleistungfur dasTexture-Mapping aufwenden,sodaßhier die maximalelokale Frameratefur eine 3D SzeneohneTexture-Mappingzu einer Abflachungder Kurve am linken Randfuhrt. ZwischendiesenRandernliegt derBereich,innerhalbdessenlokaleundRemote-Visualisierungoptimalkom-biniertwerdenkonnen,dadie jeweiligeLastambestenverteiltwird.

Einteilung der Level-of-Information-Skala: ä & $*( , ä &W+C-Die obenbeschriebeneKlassifizierungderTestrechnerfuhrt zu einerdynamischenEinteilungderLoI-SkaladesSchiebereglersaufClient-Seite.Bei derSelektioneinesObjektesdesserver-seitigen3D Dokumenteswird dieAnzahlderbenotigtenDreieckefur diesesObjektmit verschiedenerKom-plexitat abgeschatzt, indem die Oberflacheermittelt und mit der Mindestauflosungmultipliziertwird. Fur einfacheObjektewie eineKugelodereinenKonuslaßtsichdieOberflachegenauberech-nen,fur kompliziertereOberflachenwird eineAbschatzungdurchdie OberflacheeinesBounding-Volumen,z.B. die Bounding-Box,herangezogen.Aus der Oberflacheund der Mindestauflosungkanndannder minimaleKomplexitatswert ù & $*( ermittelt werden,wie es in Abschnitt8.3.3be-


Abbildung8.10:Leistungsbewertungfur Client2 (Unix-Rechner).

Abbildung8.11:Leistungsbewertungfur Client3 (Win-PC).


schriebenwurde.DerZusammenhangvonKomplexitatswertundAnzahlvonDreieckenmußdafurmit Hilfe desOpenInventorAPI im vorausbestimmtwerden.DermaximaleKomplexitatswertù &,+.-ergibt sichausderoberenGrenzefur die Datenmengepro Objektder jeweiligenL-Klasse.In Ab-bildung8.12sinddie Wertefur ù & $*( und ù &W+C- fur die verschiedenenRechnerbei derAktivierungeinfacherObjektemit unterschiedlichenAbmessungenaufgelistet.

Abbildung 8.12: Bestimmungder Schranken ù & $*( und ù &W+C- und der entsprechendenLoI-Ubergange.

AusdenWertenvon ù & $*( und ù &W+C- ergebensichdieUbergangezwischenverschiedenenObjek-treprasentationenwahrenddesArbeitensmit einem3D Dokumentfur die verschiedenenBenutzer.Die Ubergangesindebenfalls in Abbildung8.12genannt.Die Bezeichnung÷ $dh ÷ji meintdabeieinenUbergangvon derObjektreprasentation÷%$ (z.B.derparametrischenDarstellung)zurObjek-treprasentation÷ki (z.B.einerDarstellungals3D Netz).

Die Ubergangewerdendabei nach bestimmtenRegeln veranlaßt.Es gilt, daß fur ù & $*(l�ù &W+C- �m�5476 bzw. ù & $*(Yn ù &,+.- �m�5476 Ubergange ÷�� h ÷�� bzw. ÷�� h ÷�� moglich sind.Wenngilt, ù & $*(Sodù &W+C- np�5476 ist nur derUbergang ÷�� h ÷�� moglich.Schließlichist fur Kom-plexitatswerte,die derBedingungù & $*(rqdù &W+C- folgen,nur derUbergang ÷�� h ÷�� erlaubt.Diesfolgt daraus,daß ùU& $*( nicht denWert Null annehmenkann,dadie vorgegebeneMindestauflosungdiesverbietet.In Abbildung8.12ist zu erkennen,daßdie Ubergangskriteriendynamischsind,d.h.von derL-KlasseeinerClient-Anwendungundvon demTyp bzw. denAusmaßendesselektiertenObjektesabhangen.

Wennein BenutzereineObjekt aktiviert, wird eineObjektreprasentationmit einergunstigenAuflosungin der passendenDarstellungsformin seineClient-Szeneintegriert. Die PositiondesSchiebereglerskanndabeizwischendenWertenù & $*( und ù &W+.- gewahlt werden.Die automatischePositionierungerfolgtdabeiso,daßdermittlereKomplexitatswertzwischenù'& $)( und ùU&,+.- gewahltwird.


8.4 Sicherheits-Managementdurch variablen InformationsgehaltvonObjektr eprasentationen

Nachdemim vorigenAbschnitteineUmsetzungfur dasKomplexitatsmanagementinnerhalbderSCA3D-Architekturbeschriebenwurde,soll in diesemAbschnittnaherauf die Moglichkeitenei-nesSicherheitsmanagementsfur 3D Dokumenteeingegangenwerden.Um mit 3D DokumenteninoffenenInformationsraumenarbeitenzu konnen,mussenMethodenzumCopyright- undVertrau-lichkeitsschutzinnerhalbeinerSoftware-Architekturrealisiertwerden.Diesgeschiehthier, indemder variableInformationsgehaltder Objektreprasentationen zum Schutzvon Originaldokumentenverwendetwird. DazuwerdenDocument-Distribution-Classesund Benutzertypenfestgelegt, dieeineKontrollederVerteilungvonKopienerlauben.NachderDiskussionvongeeignetenMethodenzumSicherheitsmanagement,diemit Hilfe desDocument-Request-Brokersimplementiertwurden,werdendannpraktischeErgebnissebeschrieben.

8.4.1 Document-Distribution-Classesfur 3D Dokumente

Zur Formulierungvon Sicherheitsinformationen, hier als IPR-Info bezeichnet,werdenverschie-deneDocument-Distribution-Classes (DDC) definiert,die festlegen,welcheUbergangevon einerReprasentationsformin eine anderefur ein 3D Dokument(global) bzw. die enthaltenenObjek-te (lokal) erlaubtsind. DieseInformation ist nebenden 3D Dokumentenin der DatenbankdesInformations-Servers gespeichert.Zusammenmit der DDC-InformationkonnenMetadaten(Au-torenname,Entstehungsdatumetc.),DatenuberDokument-bzw. Objekttypenund eineWert ì äfur die maximaleAuflosungvon Kopienin derDatenbankdemDokumentzugeordnetsein.BeimEinleseneinesDokumenteswerdendie IPR-InfosausderDatenbankausgelesenund in denSze-nengraphenalsDatenfeldeinesLabel-Knotensintegriert (vgl. Abbildung6.11).DazuwerdenallebenotigtenInformationenin einerfestgelegtenSyntaxin einerTextkettezusammengefugt, wie esdasfolgendeBeispielzeigt:

“ Metadata:Author=...,Date=XX.YY.ZZ; DDC:DDC-A,mC=0.5; oivType=Sphere“Bei der SelektioneinesObjekteswird die InformationdesIPR-Label-Knotensin der Unter-

gruppe,in dersichdasObjektbefindet,ausgelesenundmit denParameternderBenutzerinforma-tion verglichen.Aus demVergleichwird dannermittelt,welcheBereichedesLoI-Reglersfur denZugriff gesperrtwerden.Bei der Aktivierungwird die IPR-Informationin ein internesDatenfelddesInterface-Objekteseingetragenundkanndortdirektweiterverwendetwerden.

Es werdenvier Document-Distribution-Classes definiert,namlich DDC-A, DDC-B, DDC-Cund DDC-D. In Abbildung 8.13 sind die erlaubtenUbergangefur die verschiedenenDocument-Distribution-Classesaufgelistet.Dabeisindjeweils auchWechselzuDarstellungsformenmit nied-rigeremInformationsgehalterlaubt,alsofur ÷ $sh ÷ $ut?v sindauchdie Ubergange÷ $sh ÷ $utxw und÷a$ h ÷a$utxy zugelassen.Falls ÷%$ut i nicht existiert (alsofur ïd�{z|n}� ) odernicht erzeugtwerdenkann,wird dieserUbergang÷a$ h ÷a$~t i nichtausgewertet.

Abbildung8.13:ErlaubteUbergangefur verschiedeneDocument-Distribution-Classes.


WennalsoeinObjektmit DDC-A gekennzeichnetist,darfeinautorisierterBenutzerKopiendesOriginalserhalten.ObdasObjektin parametrischerDarstellungsformoderals3D Netzvorliegt, istdabeiersteinmalnicht ausschlaggebend,d.h. fur ein 3D Netz mit DDC-A durfen Kopienals 3DNetzmit voller Auflosungverteiltwerden.

8.4.2 Festlegungvon Benutzertypen

Fur dasAnwendungsszenariowerdenBenutzermit unterschiedlichenZugriffsrechtendefiniert.ImeinfachstenFall existierenvierBenutzertypen,namlichGast, Mitglied, Administrator bzw. Besitzer.DanebensolltenaberauchBenutzermit individuellenZugriffsrechtenzugelassenund unterstutztwerden.GemeintsindhierBenutzer, diemit einemDL-ServerzumBeispieleinmaligalsGastbeimDurchsuchenverschiedenerInformationsquellenarbeitenoderals Mitglied einesDiensteseinge-tragensind.Durch Erwerbvon RechtenkonnenBenutzerauchOriginalkopienvon Dokumentenerhalten.Der Administratorist fur die PflegedesSystemsund die Inhalteverantwortlich undhatdafur freienZugriff aufalleKomponentenundDokumente.

Die BenutzertypensinddurchAttributegekennzeichnet,diediemaximalerlaubteDarstellungs-form von Objektkopienin derClient-Szenewiderspiegeln.DurchAngabeeinermaximalenDDCundeinesmaximalenKomplexitatswertesergebensichdie Regeln,nachdenenKopienalsObjekt-reprasentationenverteilt werdendurfen.In Abbildung8.14sindfur die obengenanntenBenutzer-typendieseBedingungenangegeben.

Abbildung8.14:BenutzertypenundihremaximalenZugriffsrechte.

Hier besitzenGasteund Mitglieder dasRecht,Objektemit demmaximalenAttribut DDC-Azu erhalten.Dies wird jedocheingeschrankt durch die Angabeder maximalenKomplexitat, diefur Gastebei ì ä��6476 bzw. fur Mitglieder bei ì ä9��64L� liegt. DadurchbekommenGastewahrenddesArbeitensmit 3DDokumentenlediglichdieBounding-Box-InformationvonObjekten,mit denensie lokal interagierenkonnen.Mitglieder konnendagegenmit relativ hochaufgelosten3D Netzenarbeiten.Fur Eigentumerbzw. einenAdministratorwird der Zugriff auf dasOriginalzugelassen.

8.4.3 Vergleichvon Dokumentinformationen und Benutzerinformationen

Die IPR-Informationen,die beimLadeneines3D DokumentesausderDatenbankin denSCA3D-Server ubernommenwerden,werdenbeim Zugriff einesBenutzersauf die Objekteausgewertet,um die aktuelleRechtesituationzu klaren.Dazuwerdendie bei derBenutzeranfragemitgeschick-tenBenutzerinformationenmit denIPR-Informationenverglichenundanschließenddie erlaubtenBereichedesLoI-Schiebereglersfreigegeben.PositionendesLoI-Reglers,die beimAktivierenei-nesObjektesdie Rechteverletzenwurden,werdenfur denBenutzergesperrt.In Abbildung8.15


sinddie Informationenauf Server-Seiteundauf Benutzerseitegezeigt,die fur dasSicherheitsma-nagementverwendetwerden.

Abbildung8.15:VergleichvonBenutzerinformationundDokumentinformation.

Der Zugriff auf Dokumenteist in drei Schrittegegliedert,die auchin Abbildung 8.15 wie-dergegebensind.Ein Benutzermußsich durchSendenseinerKennungund einesPasswortesamServer authentifizieren.Die Login-InformationenverschiedenerBenutzerwerdendabeiamSerververwaltet.NachderAuthentifizierung,dieautomatischbei jedemZugriff vorgenommenwird, kannder BenutzerdasgewunschteObjekt auswahlen.Bei der Selektionwird der Benutzertypund dieL-Klasseder Client-Anwendungan den Server als ParametereinesRemote-Document-Callge-schickt.AusdiesenParameternunddenInformationenuberdasDokumentamServerwerdendanndie Werte ù & $*( , ù &,+.- undderWert ù��.��" , derdengesperrtenBereichdesLoI-Reglersfestlegt, be-stimmtund zur Client-Anwendungubertragen.Dort wird derLoI-Regler bzw. dasentsprechendePanel-GUIentsprechendeingestellt,sodaßderBenutzerInformationenuberdieoptimalenDarstel-lungsformdesgewahltenObjektesunddiegesperrtenDarstellungsformenerhalt. Im drittenSchrittwahltderBenutzereineeigeneLoI-Positionaus,die innerhalbdeserlaubtenBereichesliegenmußund innerhalbdesoptimalenBereicheszwischenù & $*( und ù &W+C- liegen sollte, und aktiviert dasObjekt.Daraufhinwird diepassendeObjektreprasentationin dieClient-Szeneintegriert.

BeimAbgleichvonIPR-InformationundUser-Informationwird in jedemFall dieserver-seitigeInformation,alsoAngabenuberDDC und maximaleAuflosung,hoherbewertet.Ein Dokument,dasmit einemAttribut DDC-B versehenist und im Original als3D Netzvorliegt, wird daherim-mernur alsBounding-Box-Darstellungubertragen.Auch wennderBenutzerdurchseineL-Klasseund seinenBenutzertypeinenhoherenLevel-of-Informationerhaltenkonnte,ist die Sicherheits-informationausschlaggebendfur die tatsachlich verteiltenObjektkopien.D.h. die MechanismendesSicherheitsmanagementsgreifenimmervor denMechanismendesKomplexitatsmanagements.Nur wenneineBenutzerdieRechteamOriginalerworbenhat,werdendieOriginaldatenalsKopieversendet,wobeisiemit einerspeziellenSicherheitsinformationfur denBesitzerversehenwerden.


Der Einsatzvon digitalenSignaturenundWasserzeichen(siehe[BB00] und[Dit00]) ist dabeieinwirksamesMittel, umdieVerteilungvon Originalkopienzukontrollieren.

8.4.4 BereitstellunggeeigneterMethodenmit demDocument-Request-Broker

Zur Realisierungdes SicherheitsmanagementswerdenMethodenverwendet,die mit Hilfe desDocument-Request-Brokers vom Client ausaufgerufenwerden.Das Interface-Objekteinesakti-vierten Dokumentobjektesbietet dieseMethodenfur den entferntenAufruf an und erlaubtdenkontrolliertenZugriff aufdieSicherheitsinformationenunddiegeschutztenDaten.Fur dasAnwen-dungsszenariodiesesKapitelswerdenzwei einfacheMethodenimplementiert,die ein BenutzerzumZugriff aufdasDokumentverwendenkann.

Um die SchutzinformationeneinesDokumentesbzw. einesObjektesdirekt abzufragen,wirddie MethodegetIPRInfo()benutzt,die denIPR-StringdesselektiertenObjekteszuruckliefert.DieArt der Weiterverarbeitungder Informationwird der Client-Anwendunguberlassenund ist nichtgeregelt.DieseMethodeunterstutztdenPunktEvaluationvonSicherheitsinformationen, derin Ab-bildung2.7desKapitels2 fur dasdort vorgeschlagenenDokumentmodellbeschriebenwurde.EinBenutzerkannauf dieseWeiseschonvor derAktivierungeinesDokumentobjektesInformationenuberdieSchutzrechte,wie z.B.denEigentumerundCopyright-Daten,oderdenDokumenttyp,wiez.B.parametrischesModell oder3D Netz,erfahren.Dadurchkannschonvor einerUbertragungdereigentlichenDokumentdatenentschiedenwerden,welcheSchrittezumweiterenArbeitenmit demDokumentunternommenwerdensollten.In derPraxiskonntez.B. ein Planer, der3D Dokumentemit einerbestimmtenAuflosungbenotigt, alsGastin einerProduktdatenbankeinerAnbieterfirmasuchen,wobei die interaktive VisualisierunguberentferntgerenderteBilddatenermoglicht wird.Wennein passendes3D Objektgefundenwurde,kannanhandder IPR-Informationvorabgeklartwerden,uberwelcheKontakteund mit welchenVerfahreneine hochaufgelosteKopie erworbenwerdenkann.

Die zweite Basismethode,die fur dasSicherheitsmanagementimplementiertwurde, ist dieMethodegetOriginal(). Diese Methodeist eine spezialisierteForm der Methode é§æ=í ýN÷Pó¦ô desInterface-Objektes.Wennein Benutzerdie RechteaneinemOriginaldokumenterworbenhat,wirdihm dieseMethodevonseinerClient-Anwendungbereitgestellt.EineBenutzer, dernicht zuvor dieRechtezur KopieeinesOriginalserworbenhat,kanndieseMethodegetOriginal() nicht ubersei-neAnwendungaufrufen,dasiegesperrtbleibt.DurchSelektioneinesObjektesundRemote-AufrufdieserMethodewerdendieOriginaldatenvomServerzumClientubertragenundderBenutzerkannsie dort lokal abspeichern.Dabeiwerdendie IPR-Informationen,die im AllgemeineneineOrigi-nalkopie verhinderthatten,fur dieseneinenVorgangaußerKraft gesetzt.DasOriginal ist dabeialsOriginalkopie zu verstehen,d.h.dasDokumentbleibt in derServer-Datenbankweitermit denvorhergultigenSchutzrechtenbestehen.

WeitereMethodenzum Sicherheitsmanagementsind denkbar. Zur Kennzeichnungvon Kopi-en konntenIntegrationsmethodenfur Wasserzeichenund digitale Signaturenim Interface-Objektimplementiertwerden.Um eineDokumentverwaltungzuermoglichen,warenauchAbfragemetho-denzumBearbeitungsstandundzudenbearbeitendenPersonensinnvoll. SchließlichkonntedurchAnbietenvonspeziellenMethoden,wie z.B.getEncryptedObject(), dieverschlusselteUbertragungmit Hilfe vonSSL-Verbindungen(Secure Socket Layer [FKK96]) erreichtwerden.


8.4.5 PraktischeErgebnissebei der AnwendungeinesabgestuftenRechtekonzepts

Das Sicherheitsmanagementinnerhalbder SCA3D-Architektursoll nun anhanddespraktischenBeispielsausAbschnitt 8.3.4 erlautertwerden.Bei der Selektionverschiedener3D Objektein-nerhalbeinesgeladenen3D Dokumenteswurdendort die Schranken derKomplexitatswerteù & $*(und ù &W+.- bestimmtunddarausdie optimaleDarstellungsformfur dasObjektamClient ermittelt.Dabeiwarennur Performanzkriterienvon Bedeutung.Nun sollendie dort gefundenenErgebnissedahingehenderweitertwerden,daßauchdieAuswirkungendesSicherheitsmanagementserkennbarwerden.Dazuwerdenfur zwei Benutzer(Mitglied undGast)undein einfachesBeispieldokumentdie Benutzerinformationunddie IPR-Info in die Auswertungmiteinbezogen.Die Ergebnissesindin Abbildung8.16gezeigt.

Abbildung8.16:Auswahlvon Objektreprasentationenmit Sicherheitsmanagement.

Das3D Dokumentist mit denAttributenDDC-B und ì ä��64L_ belegt, darf alsonur als3DNetzmit derangegebenenmaximalenKomplexitat ubertragenwerden.DerTyp ist mit ýNü��gã!þoñAæ=ë@ægekennzeichnet,d.heshandeltsichum ein parametrischesOpenInventor-Kugelobjekt. Die Benut-zerinformationgibt nebendenLogin-DatenauchdenBenutzertyp(Mitglied bzw. Gast)und dieL-Klasseder Client-Anwendung(L2) an. AußerhalbdieserRechtesituationkonnteder Benutzersowohl dasOriginal alsauch3D Netzemit einerAuflosungzwischenù'& $*( �I64\á und ù'&W+C-��264L�anfordern.DieseErgebnissewarenin Abschnitt8.3.4ermitteltworden.Mit denEinschrankungendurchdieDocument-Distribution-ClassunddiemaximaleAuflosungdes3D DokumentesdarfdasMitglied nunbei aktiviertemSicherheitsmanagementnur 3D Netzemit einermaximalenKomple-xitat von ù'�C��"��Q64�� erhalten,daOriginalkopiendurchdasDDC-Attribut nicht zugelassensind.Der Benutzer, deralsGastmit demInformationssystemarbeitet,darf im Gegensatzdazunur mitder Bounding-Box-Informationder Objekte ù��.��"p��6476 lokal arbeiten,wahrender vom Servernaturlich genausomit Bilddatenversorgt wird wie daseingetrageneMitglied.

DemBenutzerwird amPanel-GUIangezeigt,welcheBereichedesLoI-Reglersempfohlenundwelchegesperrtsind.InnerhalbdesempfohlenenBereichesist nocheineWahlzwischenverschie-denenAuflosungenmoglich,sodaßderBenutzereineeigeneLoI-Positioneinstellenkann.Die imBeispielgewahltePositionentsprichtdemmaximalerlaubtenKomplexitatswert ��òEü��~ù��.��"M�64�� . Als Resultatwird ein Kugelobjektmit Radius÷3�2��476 (interneLangeneinheiten)als3D Netzmit insgesamt��_tá�� Dreieckenin dieClient-Szeneintegriert,wobeieineDatenmengevonungefahr��_56 MByte ubertragenwerdenmuß. In Abbildung 8.17 ist ein praktischesBeispiel anhanddes


SCA3D-Prototypengezeigt.EinemBenutzerwerdenje nachseinerRechtesituationverschiedeneObjektreprasentationen lokal zurVerfugunggestellt.In diesemFall ist diesentwederdieBounding-Box-Informationim Navigationsraum,um ein Objekt z.B. besserlokalisierenund unterscheidenzu konnen,ein 3D Netz mit einembestimmtenKomplexitatswertoderdasOriginal als NURBS-Flache.

Abbildung 8.17: VerfugbareObjektreprasentationen: Bounding-Box-Information, 3D Netz oderoriginaleNURBS-Flache.

Durch Auswahl geeigneterEinstellungenfur die Attribute DDC und maximaleKomplexitatwird zusammenmit den Benutzerrollenein abgestuftesRechtekonzepteingefuhrt. Dabei ist esmoglich,daßdieAuflosungderKopienaufBenutzerseiteandieerworbenenRechteangepaßtwird.In demhier diskutiertenAnwendungsszenariowurdennur die BenutzerrollenGast,Mitglied undAdministratorbzw. Besitzeruntersucht.Fur ein erweitertesSzenariomit individuellen RechtenkanndiesesKonzeptabermit einerverfeinertenAbstufungumgesetztwerdenundermoglicht da-mit einflexiblesSystemzurRechtevergabein offenenInformationsraumen.

8.5 Zusammenfassung

In diesemKapitel wurdenanhandeinesAnwendungsszenariosdie AnforderungenbeimArbeitenmit 3D Dokumentenin offenenInformationsraumendiskutiert.Also Anwendungsumfeldwurdendafur verteilteDigitale Bibliotheken gewahlt, die in ihren Eigenschaftenden offenenInformati-onsraumennahekommen.InsbesondereTechniken zum Umgangmit komplexen und geschutz-ten 3D Dokumentenwurdendabeials notwendigeVoraussetzungfur ein anwendungsorientier-tesSystemerkannt.Die SCA3D-Software-Architekturwurdedannim Hinblick auf ihr Potentialfur ein Komplexitatsmanagementund ein Sicherheitsmanagementin heterogenenverteiltenUm-gebungenuntersuchtund Umsetzungsmoglichkeiten beschrieben.DurchKlassifizierungvon DL-Dokumentenbezuglich ihresInformationsgehaltesund derEinordnungvon Client-Anwendungenin LeistungsklassenwurdedasKomplexitatsmanagementrealisiertundMessungenin einerTestum-gebungvorgestellt,diedieWirksamkeit desKonzeptesbelegen.

Fur dieRealisierungdesgefordertenSicherheitsmanagementswurdenDocument-Distribution-Classeseingefuhrt,dieeineKontrollederVerteilungvonKopienerlauben.Mit Hilfe vonBenutzer-typenin einemRollenmodellwurdederZugriff auf die soklassifiziertenDokumentereguliert und


an die aktuelleRechtesituationangepaßt.Mit Hilfe speziellerMethodendesDocument-Request-BrokersderSCA3D-ArchitekturwurdendemBenutzerMoglichkeitenzumUmgangmit geschutz-tenDokumentenzur Verfugunggestellt,wobeidie Funktionalitat durchImplementierungweitererMethodenjederzeitauszudehnenist. PraktischeErgebnissebeim Arbeiten mit 3D DokumentenbeiaktivemSicherheitsmanagementwurdenvorgestelltunddieFlexibilit at beiderUmsetzungvonRechtekonzeptenhervorgehoben.

Kapitel 9

KooperativesArbeiten innerhalb derSCA3DAr chitektur

In diesemKapitelwird dieSoftware-Architekturim Hinblick auf ihre Einsetzbarkeit undihre Vor-teilefur kooperativeAnwendungenuntersucht.DamitsindsolcheAnwendungengemeint,diemeh-rerenBenutzernerlauben,synchronisiertmit denInhaltenvon 3D Dokumentenzu arbeiten,wobeisie durchverteilte3D Visualisierungunterstutzt werden.Ansatzefur verteilteVisualisierungssy-stemefur mehrereBenutzerwurdenbereitsin Kapitel 4 beschrieben.Hier soll esvorallemdarumgehen,die neuenMoglichkeiten der SCA3D-Architekturbeim Arbeitenmit 3D DokumenteninsolchenMehrbenutzerumgebungen zu untersuchen.Besondersdie Vorteile im Umgangmit kom-plexenundgeschutztenDokumentenin heterogenenUmgebungen,d.h.solchenmit Unterschiedenim Hinblick auf Bandbreiteund lokaleLeistungzwischendenBenutzerrechnern,werdenbespro-chen.Mit derdynamischenKombinationvonlokalerundRemote-VisualisierungdecktdieSCA3D-ArchitekturdasSpektrumzwischenSystemen,die nur mit lokalerVisualisierungundDatenrepli-kation arbeiten,und reinenRemote-Visualisierungssystemen ab. Es soll untersuchtwerden,aufwelcheWeisesich die wichtigstenAnforderungenan eineverteilte3D Visualisierungsumgebungfur mehrereBenutzerdurchdiesenkombiniertenAnsatzrealisierenlassen.

9.1 Einf uhrung: Anforderungenan die Visualisierungsumgebung beider Kooperation

Die wichtigstenAnforderungenanMehrbenutzersystemezur verteilten3D Visualisierungwerdenim folgendenbeschrieben,wobei Basisanforderungenund fortgeschritteneAnforderungenunter-schiedenwerden.Diehl nenntin [Die01] als Basisanforderungenan einevirtuelle Mehrbenutzer-welt:

� Objektehinzufugen und entfernen: WennBenutzersich anmeldenoderabmeldenbzw. Ob-jekte in ein Dokumenteinfugenoder entfernen,sollen alle anderenBenutzer-Szenendie-seVeranderungenwiederspiegeln.DazumussenSzenenveranderungendurchObjektubertra-gungenund-integrationmoglichseinundObjekteundBenutzermussenregistriertwerden.

� Kommunikationvon verandertenObjektzustanden: Objektewerdendurch eine graphischeReprasentation,durcheinenZustandund ein Verhaltenbeschrieben.Alle AnderungenamZustandderObjekte,z.B. ihrePosition,Ausrichtung,Materialeigenschaften etc.,sollenallen

146

KAPITEL 9. KOOPERATIVES ARBEITEN INNERHALB DERSCA3DARCHITEKTUR 147

BenutzernmoglichstzumgleichenZeitpunktsichtbargemachtwerden.WenndasVerhaltensich andert,z.B. weil die Zugriffsrechteeingeschrankt werden,mußsich diesauchauf alleBenutzeranwendungenauswirken. Oft wird die Anwesenheitder Benutzerdurchdie Posi-tionenihrer Kamerasund desBlickwinkels denanderenTeilnehmersichtbargemacht.DieObjektein denverteiltenSzenen,die einenBenutzervertreten,werdenalsAvatare bezeich-net.Auchdie Zustandsanderungvon Avatarenmussenimmerkommuniziertundaktualisiertwerden.

� Benutzerkommunikationdurch Audio/Video-Streaming: Durch Audio- bzw. Videokonferen-zensoll dieKooperationzwischendenBenutzernerleichtertwerden.Dazuwird in derRegelAV-Streamingverwendet,umeineunterbrechungsfreieKommunikationzuermoglichen.

Als fortgeschritteneAnforderungenan Mehrbenutzersystemewerden vorallem die beidenAspektederAdaptivitat andieRandbedingungenwahrenddesArbeitensunddesSicherheitsmana-gementsfur Daten-undRechnerzugriff angesehen.

� Adaptivitat andieRandbedingungen: EineClient-Anwendung,diesichaneinerkooperativenVisualisierungskonferenz beteiligt,solltedurchdie ubertragenenDatenund lokal ablaufen-denProzessenicht uberlastetwerden.Die zu ubertragendeund lokal zu bearbeitendeInfor-mationsmengesollte dynamischso angepaßtwerden,daßdie VerzogerungzwischenallenTeilnehmernin einemfestgelegtenRahmenbleibt.

� Sicherheitvon Datenund beteiligtenRessourcen: Die Bearbeitungund Verteilungvon 3DDokumentensollte in einer Weise kontrollierbar sein, daß kein unerlaubterZugriff, un-erwunschteDatenmanipulationoderVerletzungvonanderenRechtenmoglichist.DerZugriffauf RechneruberdasNetzwerksolltenicht zu Sicherheitslucken unddamitzur GefahrdungderbeteiligtenRechnerfuhren.

Bei der RealisierungdieserAnforderungensind folgendePunktezu beachten.Erstenswer-denin einemNetzwerkeventuellnur niedrigeBandbreitenmit einerhohenVerzogerungszeitzurVerfugungstehen.Auf jedenFall werdendieseParameterfur verschiedeneBenutzervariieren.Zweitensist die Heterogenitat desNetzwerkesbezuglich der verwendetenTechnologie,wie Be-triebssystemenund vorhandenenProgrammbibliotheken, zu berucksichtigen.DrittensmussendieProzesse,die fur die verteilteInteraktionlokal ablaufen,im gesamtenRechnernetzsynchronisiertwerden.ViertenssolltenMoglichkeitenzumFehlerausgleicheingefuhrt werden.Funftensschließ-lich sollteeinesolcheUmgebungmit derAnzahl ihrer Benutzerskalieren,d.h.bei steigenderAn-zahlvonBenutzersolltedasVerhaltendesSystemssichnichtzustarkandern.InsbesonderesolltendieVerzogerungzeitenbeimArbeitenmit Objektennichtunverhaltnismaßigansteigen.

9.2 KooperativeSzenarienunter VerwendungdesSCA3DKonzeptes

Mit Hilfe der prototypischenImplementierungder SCA3D-Architekturwird ein Mehrbenutzer-Szenarioumgesetzt.Die Aufteilung in einenNavigationsbereichund einenlokalenInteraktions-bereichsoll hier im Hinblick auf die verbesserteUnterstutzung kooperativen Arbeitensunter-suchtwerden.In Abschnitt 5.7 wurde bereitsdaskooperative Modell der SCA3D-Architektur,das mit Hilfe eines CORBA-basiertenAnsatzesarbeitet, vorgestellt. Nun sollen die Anwen-dungsmoglichkeiten, die durchdiesentechnischenAnsatzrealisierbarsind, ausgewertetwerden.Bei demhier verwendetenKooperationsmodellhandeltessich,um ein Client-Server-Modell mit


Unicast-Kommunikation.AndereAnsatzewie Peer-to-Peer-Konzepte(siehez.B.dasDIVE-System[CH93]) werdenhier nicht untersucht,da dasClient-Server-Modell fur denAnwendungsbereichoffenerInformationsraumebzw. Digitaler Bibliotheken mit Informations-Servern vorgegebenundvorteilhafterist. Multicast-Kommunikationkonntez.B. zur Synchronisationvon gleichzeitigakti-viertenObjektenbenutztwerden,wobeialleBenutzereineMulticast-Gruppebilden,diedasgleicheObjektaktiviert haben.

DasKonzeptvon Navigations-undInteraktionsbereichen kannvorteilhaftsowohl im Hinblickauf adaptive 3D Visualisierungalsauchfur dasSicherheitsmanagementbei derKooperationzwi-schenBenutzernangewendetwerden.Die Kooperationin heterogenenNetzenmit Benutzern,diesehrunterschiedlicheEndgerateundAnbindungsbandbreiten verwenden,wird damitmoglich.AlsBeispielseidie ZusammenarbeiteinesProjektleitersaufeinerBaustellemit PDA undmobilerAn-bindungund einemIngenieurim Buro einer beauftragtenFirma mit einemleistungsstarken PCundeinergutenAnbindunggenannt.Die BearbeitungeinesAnderungswunschesaneinemBauteilkannmit demhier vorgestelltenAnsatzin diesemPraxisfall ermoglicht werden,wobei auchdieRechtesituationfur geschutztetechnischeInformationenberucksichtigtwerdenkann.

9.2.1 Nutzung von Navigations-und Interaktionsbereichen

Da in dem beschriebenenSzenariodie graphischenReprasentationsformenvon 3D ObjektenindenClient-Szenenvariableunddynamischverteiltwerdenkonnen,kanndieVerzogerungszeitzwi-schendenBenutzerndurchAnpassungderClient-Szenenminimiertwerden.Ein Benutzermit einerschlechtenPerformanzarbeitetdannmit Reprasentationsformen,die die verfugbarenRessourcenschonen,wahrendeineBenutzermit guterAnbindungund lokaler Leistungmit hochaufgelostenObjektreprasentationen in seinerClient-Szenearbeitenkann.Die Rechtesituationfuhrt zu einerKontrolle der Reprasentationsformenin denClient-Szenen.Auch wennder schwacheClient dieMoglichkeit nutzt, hauptsachlich lokal zu arbeitenund dasServer-Feedbackzu verringern,wer-denalle Aktionen uberdenRuckkanalsofort zum Server gesendet.Der starke Client kanndieseAktionennahezuin Echtzeitsehen,daer mit einemschnellenServer-Feedbackversorgt wird. DieVerzogerungvom Client zumServer ist alsoimmergering,wahrenddie Verzogerungvom ServerzumClient uberdasvisuelleFeedbackreguliertwerdenkann.FallsderschwacheClient in diesemSzenariosich in einerPhasebefindet,in der er lokal nicht mit Objekteninteragierenmuß,kanner dasServer-Feedbackauf einenmaximalenWert regeln,um die AktionenderanderenBenutzermoglichstsofortzusehen.

In Abbildung9.1 ist eineSzenariomit zwei Benutzerngezeigt,die innerhalbeines3D Doku-mentesauf Server-SeitenavigierenundgleichzeitigObjektein ihremjeweiligenInteraktionsraumlokal bearbeiten.Der Interaktionsraumkanndabeiauf Server-Seitemit einemraumlichenBereichverknupft werden,sodaßbeiderBewegungeinesBenutzersin derSzenedieObjektein diesemBe-reichaktiviert werden.Wennsichdie Interaktionsraumein diesemSzenariouberschneiden,konnendieBenutzergleichzeitiglokal aufObjektezugreifen.DurchFestlegungvonRegelnzumgleichzei-tigenZugriff mußeineInteressenkollision vermiedenwerden.Die einfachsteWeisezur Regelungbestehthier in derVergabeeinesTokens,derdasalleinigeZugriffsrechtauf ein gleichzeitigakti-viertesObjektfur einenZeitabschnitteinemBenutzerzuordnet.Auf Anfragewird derTokendannweitergegebenbzw. falls langereZeit keineInteraktionstattfindetwird derTokenautomatischfrei-gegeben.


Abbildung9.1:KooperativesSzenarioinnerhalbderSCA3D-Architektur.

Synchronisationder Navigation

Um einenkooperativen visuellenEindruck bei den Benutzernzu erzeugen,werdenverschiede-ne Techniken zur Synchronisationvon Blickrichtung-und position(Kamerasynchronisation)undzur Reprasentationder Benutzerin der SzenedurchAvatareeingesetzt.In diesemAbschnittsolldieKamerasynchronisationnaherbeschriebenwerden.In derSCA3D-ArchitektursindzweiArtenderKamerasynchronisationrealisiert,namlicheinerseitsgemeinsameNavigationundandererseitsunabhangigeNavigation.GemeinsameNavigationbietetsichzumBeispielbeieinemTutor-Klasse-Szenarioan,beidemeineGruppevonSchulernvoneinemTutordurcheinvirtuellesModell gefuhrtwird. Fur anderekooperative Anwendungen,wie z.B. demgemeinsamenBearbeiteneinesKon-struktionsbauteils,wird in denmeistenFalleneineunabhangigeNavigationstattfinden.

In Abbildung9.2 sinddie Ablaufebei derNavigationssynchronisation verdeutlicht,wobeieinaktiver undein empfangenderClient dargestelltsind.Die SynchronisationderKameraserfolgtda-bei immer uberdenServer, der die Kameraparameterweiterverteilt und gleichzeitigein visuellesFeedbackin Form von Bilddatenan die Client-Anwendungensendet.Die BilddatenwerdenaufClient-Seiteauf die Projektionsflacheabgebildet,die sich mit der Kamerabewegt und auchihreOrientierungvor derKamerabeibehalt. Die UbertragungderAktionenerfolgtdabeiin beideRich-tungenmoglichstschnell(CORBA RPCs),wahrenddie Geschwindigkeit desvisuellenFeedbacksuber die Remote-Framerategeregelt werdenkann. Wenn ein Benutzereine Aktion zum Serversendetwird seineKennung(ID) als Ubergabeparametermitgeliefert,sodaßderServer die Client-Anwendungidentifizierenkann.Wennder Server die Aktion weiterleitensoll, wird die Kennungderzu rufendenClient-AnwendungandenAktionsnamenangehangt,dadie CORBA-Referenzen


dereinzelnenBenutzernachdiesemSchemabenanntwerden.

Abbildung9.2:SynchronisationderKamerasunddesvisuellenFeedbacks.

In Abbildung 9.1 sind auchAvatarefur die beidenBenutzerals einfache3D Objektein dieServer-Szeneintegriertworden.Ihr Interaktionsbereichwird hierdurcheinenkugelformigenRaummit derKamerapositionalsMittelpunkt reprasentiert.Wennein Benutzerim 3D Dokumentnavi-giert,werdendieanderenBenutzeruberdasvisuelleFeedbackdaruberinformiert,d.h.dieAvatarebefindensich hier auf Server-Seiteund mussennicht wie bei anderenSystemenin den Client-Szenenreprasentiertwerden.

� GemeinsameNavigation: Bei der gemeinsamenNavigation werden alle ParametervonClient-KamerasundServer-Kamerazu jedemZeitpunktsynchronisiert.Wennein BenutzerseinenBlickpunkt andert,werdendieseneuenParameterzumServer gesendetunddort aufdie Kameraangewendet.Gleichzeitigwerdendie Parameteran alle anderenBenutzerge-sendet.Hierbeiist daraufzuachten,daßdieursprunglichsendendeClient-Anwendungnichtsynchronisiertwird, dasonstSchleifeneffekte auftreten,die dasSystemblockierenkonnen.Die Kameraparameterdienendazu,diePosition,dieOrientierungunddenFokusderKameraeinzustellen.Wie in Abbildung9.2durchPfeileangedeutetangedeutet,besitzteineKameraalle sechsFreiheitsgradederBewegung,d.h.Translationentlangderdrei GrundachsenundRotationum dieseAchsen.Ein BenutzerderdasRechtdazuhat,kannfur alle BenutzeraufgemeinsameNavigationumschalten,d.h.einTutorkonnteaufdieseWeisefur einenZeitraumdieKamerafuhrungubernehmen.

� Unabhangige Navigation: Wenn nun die Benutzereigenstandig navigieren wollten, wer-


dendie Kameraparameterlediglich zwischenClient-AnwendungundServer synchronisiert.Die KamerasynchronisationzwischenServer undClient wird alsoausgeschaltet.Um jedemBenutzerdasvisuelle Feedbackzu liefern, dasseinenKameraparameternentspricht,wirdnun am Server in festgelegter Reihenfolgedie 3D Szenemit denindividuellenKamerapa-rameterngerendert.Die Bilddatenwerdendannin denentsprechendenBildbuffer desBe-nutzergeschrieben.Dabeikonnendie verschiedenenAnforderungender einzelnenClient-AnwendungenandasvisuelleFeedbackberucksichtigtwerden,sodaßleistungsfahigeClient-Rechnerauchin diesemModusmit einerhoherenFramerateversorgt werdenkonnen.MitdieserMethodewird eineunabhangigeNavigationderBenutzerermoglicht,wobeiallerdingsdieLeistungsfahigkeit desServersentsprechendgutseinmuß.Mit steigenderAnzahlderBe-nutzer, die unabhangignavigierenwollen, wird entwederdie Server-Last im Verhaltnis derangefordertenFrameratensteigen,oderwennderServerausgelastetist, werdendieBenutzermit einerverringertenBildwiederholrateversorgt werden.

9.2.2 Unterstutzung der Kooperationdurch Informationsvisualisierung

Bei der Anforderungsanalysein Abschnitt6.2 wurdenbereitsdie Bedienelementein der Client-Szeneangesprochen,die zur VisualisierungdesZustandsder Mehrbenutzerumgebung verwendetwerden.Diesedienenzur Informationsvisualisierung im kooperativen Arbeitsprozeßundgehorennicht zu demeigentlichen3D Dokument,dasalsTeil derClient-Szeneangezeigtwird. Die wich-tigstenKomponenten,die in die Client-Szeneund die Server-Szenezu diesemZweck integriertwerden,sind Benutzerlogos,Navigationssignaleund Avatar-Objekte.Die erstenbeidenElemen-te werdenim Interaktionsraumeingeblendet,wahrenddie Avatar-Objektein denNavigationsraumeingefugtwerden.Die BenutzerlogosunddieNavigationssignalewerdengegenuberdersichbewe-gendenKamerastetssoausgerichtet,daßsieauchbei derNavigationortsfestim unterenRanddesAnwendungsfensterserscheinen.

� Benutzerlogos: JedemBenutzerwird ein Logo zugeordnet,dasalsPolygonmit einerFoto-textur in der Client-Szenerealisiertwird. DasFoto desBenutzerswird lokal abgelegt undbei Bedarf eingelesen.Außerdemwird eine Farbstreifenan der unterenKante desLogoseingeblendet,der fur jedenBenutzereineeigeneFarbefestlegt, die zur Markierungvon se-lektiertenObjektenundAvatarenbenutztwird. In Abbildung7.7sindBenutzerlogosfur zweikooperierendeBenutzergezeigt,denenjeweils aucheineFarbezugeordnetwurde.Auch furdenBenutzerderjeweiligenClient-Anwendungwird lokal daseigeneLogoeingeblendet,umeinenvollstandigenUberblickderBenutzerzu bietenund die verknupfte Farbebekanntzumachen.Die ReihenfolgederEinblendungenderLogosist in allenClient-Szenensofestge-legt, daßdaseigeneLogo in derrechtenunterenEcke desClient-GUI erscheintundweitereBenutzerdynamischin derReihenfolgeihrer Anmeldunglinks davon eingeblendetwerden.Wennein Benutzersich abmeldet,wird dasLogo ausallen Client-Szenenentferntund dieFarbefreigegeben.

� Navigationssignale: Ebenfalls in Abbildung7.7ist in derlinkenunterenEckeeingraphischesObjekteingeblendet,dasalsNavigationssignalbezeichnetwird. Esdientdazu,demBenutzereinerseitsdenaktuellenNavigationsmodusanzuzeigenundandererseitsdenZustandderOb-jekte im Interaktionsraumzu signalisieren.Die zwei ElementedesNavigationssignalssindein Kugelobjekt,dasentwedergrun oder rot gefarbt ist, und ein kleineres,auf die KugelaufgesetztesWurfelobjekt,dasentwederdieFarbeBlauoderdieFarbeRotannimmt.Im ein-zelnenist die Funktionalitat wie folgt festgelegt: Bei gemeinsamerNavigationerscheintdie


KugelbeiallenBenutzerngrun,wahrendunabhangigeNavigationdurchdieFarbeRotkennt-lich gemachtwird. Das Umschaltenzwischenden Navigationsmodierfolgt uber eine Ta-stenkombination.Mit Hilfe desWurfelobjekteswird angezeigt,obdie Verbindungzwischendemselektiertenserver-seitigenDokumentobjektundderclient-seitigenObjektreprasentati-on vollstandigaktiviert ist. Da meistmehrereObjekteim Interaktionsraumvorhandensind,wird dasaktuellbearbeiteteObjektamServer undamClient internspeziellmarkiert.DurchdoppeltesAnklickeneinesClient-Objekteswird diesesvollstandigaktiviert. Dieswird durchdie blaueFarbedesWurfelobjektessignalisiert,wahrendeinenicht vollstandigeVerbindungbei der Interaktionmit einerrotenFarbung angezeigtwird. In diesemFall kannein Objektim Interaktionsraumz.B. verschobenwerden,ohnedassich diesauf dasServer-Dokumentauswirkt.Ein Zustand,der im allgemeinennicht gewunschtist und der deshalbdurcheinWarnsignalkenntlichgemachtwird.

� Avatar-Objekte: Die AnwesenheitvonmehrerenBenutzernbeiderkooperativenBearbeitungeines3D DokumenteskanndurchAvatar-Objektewahrnehmbargemachtwerden.Dazuwer-denfestgelegte geometrischeFormen,z.B. zwei farbigeaufeinandergestellte Quader(sieheDIVE-System[CH93]), in dieSzeneneingebracht.DieseAvataresindjeweilsmit einemBe-nutzerverknupft, indemsiederBewegungderKameradiesesBenutzersfolgen.DerBenutzerselbstsiehtdannein ortsfestesObjektin seinerSzene,mit demer sicheingeschrankt identi-fizierenkann,wahrendandereBenutzerdurchdenAvatardieaktuellePositiondesBenutzerserkennenkonnen.In Systemen,diemit DatenreplikationundlokalerVisualisierungarbeiten,wird in jederClient-SzeneeinAvatar-Objektfur jedenBenutzerintegriert.Alle dieseAvataremußenin ihren Bewegungensynchronisiertwerden,wodurchbei einersteigendenAnzahlvon BenutzerndieNetzlaststarkansteigt.

Abbildung9.3: Avatare(grunerundroterQuader)von zwei Benutzerngesehenvon einemdrittenTeilnehmer.


In der SCA3D-ArchitekturwerdenAvatarein die Server-Szeneintegriert und die Synchro-nisationerfolgt uberdie Kameraparameter, die fur die NavigationzumServer gesendetwer-den.Auch bei eineransteigenderAnzahl von Benutzernwird die Netzlastauf dieseWeisenicht zusatzlich zunehmen.Das Avatar-Objekt fur einenBenutzerwird dazubei der An-meldungin die Server-Szeneals Gruppeeingefugt, die auseinemSeparatorknoten,einemTransform-Knoten,einemMaterialknotenund dem geometrischenAvatar-Objekt besteht.Durch Synchronisationder jeweiligen Kameraparametermit dem Transform-KnotenwirddasAvatar-ObjektstetsentlangderNavigationroutedesBenutzersgefuhrt undentsprechendausgerichtet.UberdenMaterialknotenwird die Farbe,die demBenutzerzugeordnetist, aufdasAvatar-Objekt ubertragen.In Abbildung9.3 ist die graphischeOberflacheeinerClient-Anwendunggezeigt,derenBenutzermit zwei anderenTeilnehmerneinekooperative Konfe-renzdurchfuhrt.Die AnwesenheitderBenutzerist dortdurchAvatare,hiereinfacheQuader-objekte,kenntlichgemacht.Die Avatarebewegensichin derServer-Szenegefuhrt durchdieNavigationder Benutzer. Die Farbeder Avatar-Objekteentsprichtdabeider farblichenCo-dierung,die fur die einzelnenBenutzervergebenwurde.Der AvatardesBenutzersselbstistin diesemFall uberderKamerapositionunddeshalbfur ihn nicht zu sehen.In derSCA3D-Architekturwurdenlediglich einfacheVersuchemit diesenAvatar-Objektengemacht,derenErgebnissein Abbildung9.3gezeigtsind.

9.3 Zugriffstranspar enzund Synchronisationvon 3D Objekten

In diesemAbschnittsoll esum Methodenzur AufrechterhaltungeineseinheitlichenZustandesderDokumentobjektegehen,diezwischenServerundClient-Anwendungenverteiltsind.Bei derBear-beitungeinesDokumentesdurchdie Benutzerwird fortlaufendderZustandderObjekteverandert.Diesgeschiehtz.B.durchManipulationderObjektparameteroderdurchTransformationbezuglicheinesder sechsBewegungsfreiheitsgrade.Auch dasVerhalteneinesObjekteskann sich andern,wennz.B.dieZugriffsrechtewechseln.SchließlichkanndasDokumentobjektamServersichdurchInteraktionsoandern,daßdiegraphischeReprasentationsformin derClient-SzenenichtmehrdurchentsprechendeManipulationangepaßtwerdenkann.Bei parametrischenObjektenam Server und3D NetzreprasentationenamClient kanndiesesProblemauftreten,daAnderungenderParameternicht immerdirekt in Operationenam3D Netzumgesetztwerdenkonnen.In diesemFall kannnurdurchvollstandigesErsetzenderObjektreprasentationdasDokumentobjektwiederausreichendge-naureprasentiertwerden.Alle dieseAnderungenanZustand,VerhaltenundgraphischerReprasen-tationsformvon Objektenmussenin der verteiltenUmgebung synchronisiertwerden.Auf dieseWeisewird durchdasSystemaucheineZugriffstransparenzrealisiert,d.h.fur denBenutzermachtesim bestenFall keinenUnterschied,oberauf lokaleoderentfernteObjektezugreift.

9.3.1 SynchroneInteraktion mit 3D Objekten durch Transform- und Manipulator -Knoten

DurchVerwendungvon Transform-Knotenin szenengraph-basierten Visualisierungsanwendungenkonnensehrviele Transformationenauf beliebige3D Objekteangewendetwerden.Der SoTrans-form-KnotenderOpenInventor-Bibliothek erlaubtdie Verschiebung,RotationundSkalierungvon3D Objekten.Die Skalierungist durchAngabedesZentrums,derOrientierungundeinesFaktor-vektorssehrflexibel einsetzbar. Um nundasserver-seitige3D ObjektentsprechenddenManipula-tionsaktionendesBenutzerszu synchronisieren,wird innerhalbdesInterface-ObjektesamServer


einTransform-Knotenin dieKopiedesaktiviertenGruppenknotensintegriert,wie esin Abbildung9.4gezeigtist.

Abbildung9.4:SynchronisierungvonObjektenmittelsderOIV-KlassenSoTransformundSoTrans-formerManip.

Beim AnlegendesInterface-Objekteswird eineKopiederaktiviertenObjektgruppeangelegt,indem alle Child-Knotenausder Originalgruppean einenneuenGruppenknotenals Kopie an-gehangt werden.Wenn nun ein Transform-Knotenvor allen Child-Knoteneingefugt wird, wer-denalle Transformationenuberdie Objektreferenzenauf dasOriginaldokumentubertragen.Hier-durch wird erreicht,daßdasOriginaldokumentnicht mit zusatzlichenKnoten versehenwerdenmußund trotzdemderZugriff auf die Objektemoglich wird. Nun wird die Objektreprasentation,diedurchdasInterface-Objekterzeugtwird, zurClient-Anwendungubertragen,wobeieinSoTrans-formerManip-Knotenvor denChild-Knoteneingefugt wird. Die Objektreprasentationwird dannindie Client-Szeneintegriert undauf demBenutzerbildschirmsichtbar. Der eingefugteManipulator-Knoten bewirkt, daßeine Benutzerdirekt durch dasBewegen von AnsetzpunktendesvisuellenManipulator-Objektesmit demEingabegerat dasselektierte3D Objekt verschieben,rotierenundskalierenkann.

Die Software-ArchitekturSCA3Dsorgt nundafur, daßderManipulator-KnotenaufClient-Seiteund der Transform-Knotenauf Server-SeitedurchAustauschder Transformationsparametersyn-chronisiertwerden.Dazuwird eineCORBA-Interfaceerzeugt,ein Implementierungentsprechen-derMethodenzumsetzenderFeldwertedesTransform-Knotensauf demServer abgelegt undeineObjektreferenzin der Client-Anwendungbereitgestellt.Alle Aktionen die der Benutzernun mit-telsdesManipulator-KnotensaufdieObjektreprasentationanwendet,werdenuberRPCsdirektaufdasObjekt im Originaldokumentubertragen.Insbesonderehat diesesVorgehendenVorteil, daßauchunterschiedlichegraphischeReprasentationsformenim Interaktions-bzw. NavigationsraumaufeinheitlicheWeiseverandertwerdenkonnen.AllerdingsbestehtderNachteil,daskeineObjekt-parameterdirektbeeinflußtwerdenkonnen,sondernManipulationimmernur uberdenUmweg des


Transform-Knotensstattfindenkann.Wennsichdie InteraktiondesBenutzersauf dasVerschiebenoderRotierenvon Objektenbeschrankt, kanndieseTechnik in allen Fallen angewendetwerden.Daherwerdeninnerhalbder SCA3D-ArchitekturdieseeinfachenAktionen auf die beschriebeneWeiserealisiert.Um einenflexiblerenZugriff aufalleParameterzuermoglichen,wird im nachstenAbschnitteinallgemeinanwendbaresVerfahrenvorgestellt.

Abbildung9.5:VerwaltungderReferenzenaufdieTransformeraufServer- undClient-Seite.

Um denZugriff auf ein Dokumentfur mehrereBenutzergleichzeitigzu ermoglichen,werdenauf Server- und Client-SeiteListender Interface-Objekte(IO) bzw. Objektreprasentationen (OR)aller Benutzerverwaltet.JedesInterface-Objekteenthalt eineReferenzauf denTransform-Knoten(T) desaktivierten Objektes,genausowie jedesOR-ObjekteineReferenzauf den entsprechen-denManipulator(TM) bereitstellt.Abbildung 9.5 veranschaulichtdieseListenverwaltung.Wennein Benutzereine Objektreprasentationen selektiert,wird der dazugehorige Manipulatorals ak-tiv gekennzeichnetunduberdasCORBA-Interfacemit dementsprechendenTransform-KnotenimInterface-Objektverbunden.Dazuwird eineNamensschemaverwendet,daseineeindeutigeZu-ordnungvon ObjektreprasentationundInterface-Objekterlaubt.DiesesNamensschemawurdebe-reist in Abschnitt6.3.2 im Zusammenhangmit demDocument-Request-Broker beschrieben,derhier zum Einsatzkommt. JedemBenutzerwird auf dieseWeisejeweils eine aktive VerbindungzwischenClient- undServer-Szenebereitgestellt,die dynamischwechselt,sobaldein anderes3DObjektbearbeitetwerdensoll. Der Benutzermußdafur lediglichdurchAnklickendasneueObjektvollstandigaktivieren.

9.3.2 Zugriff auf Objektparameter uber dynamischerzeugteAufrufschnittstellen

Bei der verteiltenBearbeitungvon 3D Dokumentensoll demBenutzerauchdie Moglichkeit ge-gebenwerden,allgemeineParametereines3D Objekteszu beeinflussen.DieseParameterkonnenz.B. die Farbeoder die Reflektionseigenschaftenbestimmen,wichtiger sind abernoch Parame-ter, die die geometrischeForm von parametrischenObjektenfestlegen.In demobjekt-orientiertenDokumentmodelleinesSzenengraphenwerdendieseParameteralsFelderin verschiedenenKnotenabgelegt.OberflacheneigenschaftensindalsFeldervonMaterialknoten(SoMaterial) abgelegt,Geo-metrieparameter(z.B.Radius,Hohe,Tiefe,Breite,etc.)sindalsFeldervonFormknoten(SoShape)angegebenundKontrollelemente(z.B.KontrollpunkteeinerNURBSFlache)in FeldernvonKoor-dinatenknoten(SoCoordinate3) definiert.DurchAnordnungdieserKnoteninnerhalbeinerSzenen-


graphgruppewird das3D Objektmit seinenspeziellenEigenschaftenfestgelegt undwird dement-sprechendaufdemBildschirmdargestellt.

Wennein Benutzerauf ein entferntes3D Dokumentauf demSCA3D-Server zugreiftundOb-jekteaktiviert, haterzunachstkeinedirekteInformationuberdiezugreifbarenParameterundderenAuswirkungauf das3D Objekt. Bei allen Interaktionen,die uberdasVerschieben,RotierenundeinfachesSkalierenhinausgehen,benotigt derBenutzerdaherAngabenuberMethodenmit denenerdieseParameterbeeinflussenkann.InsbesonderemußdiekorrekteForm(Syntax)unddieBedeu-tungeinesMethodenaufrufs(Semantik)in einerverstandlichenund durchdie Client-AnwendungumsetzbarenFormmitgeteiltwerden.Im einfachenFall einesQuaderobjektessollendemBenutzeralsodurchseineClient-AnwendungdreiBedienelementezurVerfugunggestelltwerden,mit denenerdiedreiKantenlangen(Hohe,Tiefe,Breite)desserver-seitigenObjekteskontrollierenkann.Dieskannz.B. durcheineEingabefensterfur Zahlenwertegeschehen,wobei fur jedesEingabefeldderMethodennameangegebenwird. Um vernunftigeWertefur einenParametereingebenzu konnen,solltederBenutzerauchein Vorstellungvon derBedeutungdesParametershaben.Wennz.B. derRadiuseinerKugelverandertwerdenkann,solltederangegebeneMethodennameesdemBenutzerermoglichen,dieBedeutungseinerInteraktionzuerkennen.Die direkteLosungfur diesesProblemergibt sich, indemdie angezeigtenMethodennamender Schnittstellezum DokumentdurcheineKombinationausAktion, FeldnameundKnotentypgebildetwerden.Also ergibt sichz.B. im FalldesKugelradiuseinMethodennamesetRadiusSoSphere. WennesmehrereParametermit ahnlicherBedeutunggibt, z.B. bei einerNURBS-Flachemit mehrerenKontrollpunktenwerdendie Feldna-menmit einerlaufendenZahlversehen,alsoz.B.setPoint1SoCoordinate3, wobeiin diesemFall dieFeldnamenderKontrollpunktedurchnumeriertwerden.

Abbildung9.6:Aufruf entfernterMethodenuberdynamischerzeugteSchnittstellen.

Internwird dieSyntaxderMethodenaufrufein einerFormangegeben,diederSpracheIDL desCORBA-Standardsentspricht.Dabeiwird nichtdasobigeNamensschemabenutzt,daszurVerdeut-lichungderMethodenbedeutungfur denBenutzerdient,sonderneswird die Methodensyntaxderim Interface-ObjektvorhandenenMethodeangegeben.Im Interface-Objektsind fur alle vorkom-mendenFeldtypenMethodenzu derenManipulationimplementiert,sodaßz.B. zumAnderneines


Kugelradiusdie MethodesetFloatParameter(inNodeIndex, in FieldIndex, in float r) aufgerufenwerdenkann.Eine Schnittstellendefinitionin Form einerTextkettewurdendannfolgendermaßenaussehen:

“ N-NodeIndex: NodeType; F-FieldIndex: FieldType; setFieldnameNodetype;Return-Parameter-List setFieldtypeParameter(Parameter-List ); N-NodeIndex:...“

DieseAngabenuberdie SchnittstelleeinesaktiviertenObjekteswerdenbei derErzeugungderObjektreprasentationalsZeichenkettein einenLabel-Knotenabgelegt, derin die ubertragenenOb-jektdatenintegriert wird. Die Client-Anwendungliest die SchnittstellendefinitionausdemLabel-Knotenund bietetdemBenutzerdementsprechendEingabeelementefur die einzelnenParameteran.

DynamischeErzeugungder Schnittstelleninformation

Die Schnittstelleninformation wird bei der ErzeugungdesInterface-Objektesam Server ausdenInformationendesSzenengraphenerstellt.Wennein3D Objektaktiviert wird unddabeieineKopiederdazugehorigenObjektgruppeim Interface-Objektabgelegt wird, kanndiebenotigteInformationuberdieeinzelnenChild-KnotenundderenFelderdabeiabgerufenwerden.Dafur sindwie obenbe-schrieben,derKnotenindex bzw. -typ, derFeldindex, -namebzw. -typ unddieAufrufdefinitionderServer-seitigenMethodenotig. Damit eineTransparenzbezuglich der Implementierungmoglichwird, solltedieAufrufdefinitionunabhangigvonspeziellenlokalenDatentypensein.OpenInventorverwendetz.B. denTyp ã/ò@ãe/�/Nú�ò¢è%í zur AngabeeinesFloat-Parameters.EineClient-Anwendungsollte aberuberdie angegebeneSchnittstelleeinfacheDatentypenverwendenkonnen.Dies wirdbeim CORBA-Standarddurchdie SpracheIDL erreicht,die einenSatzan Basisdatentypenfest-legt. Beim ubersetzender IDL-Definition in die jeweilige Programmiersprachewerdendie Daten-typen dannangepaßt.Damit allgemeineDatentypen(z.B. /rú�òEè%í ) von entferntenAnwendungengesetztwerdenkonnen,werdenim Document-Request-Broker innerhalbdes Interface-ObjektesMethodendafur direkt implementiert(z.B. ç¢æ�í�/Nú�òEè�í4êNè%ëEè%ì�æ�í æ�ë,ó�/£ï¿æ=ú�î�[ õ§è%úu oæ¢ô ). InnerhalbderMethodewird danndie implementierungsabhangige Methodezum SetzendesParametersaufge-rufen(z.B.Field.setValue(value)).Die ZuordnungvoneinemFelddesspeziellenDatentypeszuderallgemeinenMethodewird bei der Erzeugungder Schnittstelleninformation vorgenommen(z.B.ã/ò@ãe/�/rú�òEè%í h /Nú�ò¢è%í h ç¢æ�í�/Nú�ò¢è%í4êNè�ëtè%ì�æ�í æ�ë ). Dazuwird eineListeverwendet,die jedenspezi-ellenDatentypmit einemBasisdatentypundderdazugehorigenim Interface-Objektimplementier-tenMethodeverknupft. Die SyntaxderMethode,alsoEingabeparameter, RuckgabeparameterundderMethodenname,wird dannin derSchnittstellendefinition abgelegt undderClient-Anwendungmitgeteilt.Durch InterpretationdieserInformationkanndie Client-Anwendungdanndie entspre-chendenParameterfullenundmit Hilfe einerSCA3D-NachrichteinenRemote-Document-Callab-setzen.

Fur ein beliebigesDokumentobjektkannauf dieseWeisedie Schnittstelleninformation dyna-mischerzeugtwerden,wobeidie Informationdannmit derObjektreprasentationubertragenwird.Im CORBA-Standardwird fur dynamischeAufrufe vonRemote-MethodenzurLaufzeit,beidenenkeineStub-Objekteim vorauserzeugtwerdenmussen,dassogenannteDynamicInvocationInter-face(DII) verwendet.Dazuschreibtdie Server-Anwendungdie Interface-Information in dassoge-nannteInterface-Repository, dasServerundClient uberdenORBzuganglichist. In einerCORBA-AnwendunggeschiehtderAufruf einerbeliebigenOperationmittel desDII in folgendenSchritten:

� Beschaffung derObjektreferenzfur dasaufzurufendeObjekt(z.B.Naming-Service).

� AbfragederSchnittstelleninformationausdemInterface-Repository


� ErzeugeneinesRequest-Pseudo-Objektsmindestensmit AngabedesaufzurufendenObjek-tes,desMethodennamensundderParameterliste.

� UbergabedesRequest-Pseudo-ObjektsandenORB,Invoke-Ausfuhrung.

� OptionalesWartenaufdasErgebnisderOperation.

� VernichtenoderWiederverwendendesRequest-Pseudo-Objekts.

Um eineahnlicheFlexibilit at beimAufruf von entferntenMethodender Interface-Objektein-nerhalbderSCA3D-Architekturzuerreichen,werdendieobenbeschriebenTechnikenzurdynami-schenSchnittstellenerzeugung verwendet.Ein kurzerVergleichderhierverwendetenMechanismenmit deneinzelnenSchrittendesDII soll die Ahnlichkeit desVorgehensunterstreichen.

Abbildung9.7:AusschnittausdemIDL-InterfacezumAufruf vonRemote-Document-Calls.

DieBeschaffungderObjektreferenzerfolgtin SCA3DbeiderSelektioneinerObjektreprasenta-tion,derenRoot-Knotenmit einemeindeutigenNamenversehenist, derAuskunftuberdasentspre-chendeserver-seitigeInterface-Objektgibt.DieAbfragederSchnittstelleninformationpassiertdannnicht bei jedemMethodenaufrufneu,sonderndie Schnittstelleninformation wird ausdemLabel-Knotengelesen,in dendieseInformationbei der ErzeugungdesInterface-Objekteseingetragenwurde.Mit Hilfe der Schnittstelleninformation wird dannein SCA3D-Message-Objekt(vgl. Ab-schnitt6.2)erzeugt,dasahnlichdemRequest-Pseudo-Objektsin CORBA diewichtigstenInforma-tionenfur denentferntenAufruf dergewunschtenMethodeenthalt. DasSCA3D-Message-Objektwird alsParameteraneinenallgemeineninvoke-Aufruf desDocument-Request-Brokersubergeben.Auf Server-Seitewird die enthalteneInformationzumAufruf derMethodedesInterface-Objektesverwendet,die derBenutzeraktionentspricht.Die ErgebnissederOperationwerdenin Form einesParameter-ObjektesalsRuckgabedesinvoke-Aufrufs andie Client-Anwendungubergeben.Wennein SCA3D-Message-Objektnicht mehrverwendetwird, wird esdurchdie Java-Virtual-Machineautomatischvernichtet.Fur einenerneutenAufruf wird einneuesSCA3D-Message-Objekterzeugt.


In Abbildung9.7ist einAusschnittausdemIDL-Interfacegezeigt,uberdasmit Hilfe derCORBA-ImplementationdiebeschriebenenRemote-Document-Callsaufgerufenwerdenkonnen.Die Struk-tur derSCA3D-Nachrichtmit ihrenKomponentenist zuerkennen.

DieserVergleichzeigt,daßdie VorgehensweiseinnerhalbderSCA3D-Architekturderjenigendes Dynamic-Invocation-Interace, wie es in CORBA definiert ist, sehr ahnelt.Der Document-Request-Broker der SCA3D-ArchitekturerweitertdabeidasDII-Konzeptfur den EinsatzbeimverteiltenArbeitenmit 3D Dokumenten.

Bereitstellungvon GUI-K omponentenzur Parametermanipulation

Um die Flexibilit at desDocument-Request-Broker-AnsatzesdemBenutzerzur Verfugungzu stel-len, solltenintuitive Eingabemoglichkeiten fur die Manipulationvon ParameternuberbestimmteMethodenrealisiertwerden.NebendenobenerwahntenTexteingabfeldernmit Angabeder Me-thodennamen,die die Bedeutungder Methodeverdeutlichen,kannauchuber3D Objekteselbstdie Parametermanipulationstattfinden.Wenn der RadiuseinesObjektesgeandertwerdenkann,konntemittles eines3D Schiebereglerelementesmit einemKugelobjektals Positionsmarke, eineintuitive Eingabeerfolgen.Bei AnderungderReglerpositionwurdesichdanndasKugelobjektver-großernbzw. verkleinernunddamitverdeutlichen,daßessichbeidemmanipuliertenParameterumeinenRadiushandelt.Fur Kugel-,Konus-,oderEllipsen-Objekteist dieseMethodesinnvoll. Furdie AnderungeinesKontrollpunktesist die VerwendungeinesTranslations-Manipulators, dereineVerschiebung in die drei Grundrichtungenerlaubt,eineguteLosung.Prinzipiell konnendie vonOpenInventor angebotenenManipulator-Knoten,von deneneseinegroßeVielfalt gibt, fur dieseZwecke erfolgreicheingesetztwerden.

9.3.3 Anpassungder Objektr eprasentationenin den Interaktionsr aumen

DamitdieObjekteim Navigations-undInteraktionsraumsynchronisiertbleiben,mussendieAktio-nendesBenutzers,die durchParameteranderungenhervorgerufenwerden,auchauf die Objektre-prasentationubertragenwerden.Wenndasclient-seitigeObjektdie gleichegraphischeReprasen-tationsformwir dasDokumentobjektbesitzt,dannkonnendie Parametermit Hilfe derSchnittstel-leninformationlokal direktangepaßtwerden.DazumussenlediglichdieMethodenzumSetzenderverschiedenenDatentypenim OR-Objektimplementiertsein,alsoz.B. setVec3FloatParameter(inNodeIndex, in FieldIndex, in int index, in floatx, in floaty, in floatz)zumSetzendesKontrollpunk-tesmit laufenderKennzahlindex einerNURBS-Flache.

Fur denFall, daßdie graphischeReprasentationsformdesClient-ObjekteseineanderealsdiedesDokumentobjektesist, muß die Anpassungim Interaktionsraumauf andereWeiseerfolgen.Wennz.B. am Server ein parametrischesObjekt uberseineParametermanipuliertwird und amClient ein 3D Netz als Objektreprasentationverwendetwird, kanndie Geometrieoperationnichteinfach ubertragenwerden.Als alternative Losungkannauf denManipulator-Knoten zuruckge-griffen werden,der zur Verschiebung und Rotationin die Objektgruppeeingefugt wurde.IndemamServer vor undnachderParameteranderungdieBounding-Boxermitteltwird, kanneinSkalie-rungsfaktor fur jededer drei Kantender Bounding-Boxberechnetwerden.Wenn è�[C��[�ù die Kan-tenlangenvor der Operationwarenund èg�u[C�U��[�ùU� die Kantenlangendanach,dannergebensich dieSkalierungsfaktorenals ç + � +C�+ , ç�� und ç B � B��B . DieseSkalierungsfaktorenwerdenalsRuckgabeparameterderOperationzumClient ubertragenundkonnendanndirektalsEingabepara-metereinerSkalierungsoperationdesManipulator-Knotenangewendetwerden.Fur relativ einfacheObjektekanndieseAnpassungubermehrereOperationsschritteausreichendsein,umdieObjektre-


prasentationandasOriginaldokumentanzupassen.SobalddieAbweichungenaberzugroßwerden,mußderBenutzerdie Moglichkeit haben,die Objektreprasentationaktiv aktualisierenzu konnen.Dies geschiehtdurchAusloseneinerUpdate-Operation,die dasObjekt deaktiviert und mit demvorhergespeichertenLevel-of-Informationneuaktiviert.

Bei der Kooperationvon mehrerenBenutzernbestehtdie Moglichkeit, daßein Dokumentob-jekt von zwei odermehrTeilnehmernaktiviert wird. Diesearbeitendannlokal mit jeweils einerObjektreprasentationdesgleichenDokumentobjektes.Damit Aktionen von einemBenutzer, dieauf dasserver-seitige3D Objekt ubertragenwerden,sichauchauf die Client-ObjektederanderenBenutzerauswirken, mussendie Operationenjeweils auchan die anderenClient-Anwendungenubergebenwerdenunddort auf die Objektreprasentationangewendetwerden.Da sichdie graphi-schenReprasentationsformender verschiedenenBenutzeraberunterscheidenkonnen(parametri-scheObjekte,3D Netze,Bounding-Box-Information), konnennicht alle Operationenauf die glei-cheWeisesynchronisiertwerden.Um trotzdemein geeignetesVerfahrenzur Synchronisationzwi-schengleichzeitigaktiviertenObjektenzu integrieren,wird der obenbeschriebeneMechanismuszurAnpassungderclient-seitigenObjekteaufmehrereClient-Anwendungenerweitert.Dabeiwirdaufgrundder verschiedenenObjektreprasentationender Benutzerimmer die SkalierungsmethodeuberdenManipulator-Knotenverwendet.DiesesVerfahrenbietetsichauchan,weil dazulediglichein statischesInterfacezu jedemClient aufgebautwerdenmuß,uberdasdie SynchronisationdesManipulator-KnotensderaktivenObjektreprasentationablaufenkann.DieseSchnittstellewird furjedenBenutzerbeiderAnmeldungaufgebautundfunktioniertwie dieschonbeschriebeneCORBA-SchnittstellezurSynchronisationderClient-Kamerasim Mehrbenutzerbetrieb. JederBenutzerkannseineObjektreprasentationaußerdemaktualisieren,sobalddie Ubereinstimmungmit demServer-Objekt,die uberim Navigationsraumbeobachtetwird, nichtmehrausreicht.

9.4 Ergebnisse: Kooperative Arbeitsprozesse mit dem Level-of-Inf ormation-Ansatzes

NachdemdieAnforderungenundKonzeptederSCA3D-Architekturin Mehrbenutzeranwendungendiskutiertwurden,sollennunpraktischeErgebnissevorgestelltwerden,diein derTestumgebungge-wonnenwurden.Zuerstwird die Prototypanwendungvon SCA3Ddaraufhinuntersucht,inwieweitsiedieAnforderungenankooperative Systemeerfullt. DannwerdenanhanddesBeispielseinesko-operativenArbeitsprozessesinnerhalbderSCA3D-ArchitekturpraktischeErgebnissevorgestellt.

Auswertungder SCA3D-Architektur bezuglich der Anforderungen

Am BeginndesKapitelswurdefur einkooperativesSystemfolgendeBasisfunktionalitat gefordert:HinzufugenundEntfernenvon3D Objekten,SynchronisationvonverandertenObjektzustandenbeiallenTeilnehmernundMoglichkeitenzur audio/visuellenKommunikationderBenutzer. Als fort-geschritteneAnforderungenwurdengenannt:AnpassungandieRandbedingungenderheterogenenUmgebung und Techniken zur Gewahrleistungder Sicherheitvon 3D Datenund Rechnern.DerPrototypder SCA3D-Software-Architekturerfullt dieseAnforderungen,wobeidie angewendetenLosungenintegralerBestandteilderArchitektursind.Lediglichfur dieaudio/visuelleKommunika-tion zwischendenBenutzernwerdenexterneTechnikenbenutzt,die parallelzu denProzessenderSCA3D-Architekturablaufen.

Die SCA3D-Architekturwurdeim Hinblick auf dasArbeitenmit 3D Dokumentenentworfen,dadurchsind Moglichkeiten zum Hinzufugenund Entfernenvon 3D Dokumentenin bestehende


DokumenteintegralerBestandteildesPrototypen.Um die Arbeit in offenenInformationsraumenflexibel zu gestalten,wurde der AnsatzeinesDocument-Request-Brokers eingefuhrt und umge-setzt.DieserAnsatzzusammenmit demkooperativenModell derSCA3D-Architektursorgt dafur,daßalleDokumentobjekteundAvatareinnerhalbdesverteiltenSystemszujederZeit synchronisiertwerden.Die ForderungnacheinerAnpassungan die Randbedingungender heterogenenUmge-bungwird durchdenLevel-of-Information-Ansatzrealisiert.DazuwerdendieObjektreprasentatio-nendesDocument-Request-Brokersmit variablemInformationsgehaltzudenClient-Anwendungenverteilt.DasSicherheitsmanagementwird ebenfallsdurchdieKontrolledesInformationsgehaltsder3D ObjekteamClientumgesetzt,wobeieineKonvertierungderDokumentobjekteamServer statt-findet. Die Sicherheitder beteiligtenRechnerwird soweit moglich durcheineAuthentifizierungbeimZugriff aufdenSCA3D-Serverkontrolliert.

Um denBenutzernauchdieMoglichkeit derKommunikationuberAudio/Video-Verbindungenzugeben,wurdenTestsmit denMBone-Toolsfur AudiokonferenzenundVideokonferenzendurch-gefuhrt (sieheauch[Kum96]). Die MBone-ToolssinduberdenWeb-Server desUniversity CollegeLondonUCL erhaltlich und wurdenvon mehrerenInstitutenentwickelt, darunterdasUniversi-ty College Londonund dasLawrenceBerkeley National Laboratory. Die freiverfugbarenWerk-zeuge,zu denenunteranderemeineAnwendungzur Sitzungverwaltung (SDR:SessionDirecto-ry), ein Video-Tool (VIC: VideoconferencingTool) undein Audio-Tool (RAT: RobustAudio Tool)gehoren,wurdenaufallenRechnernderTestumgebunginstalliertundeineAudio/Video-Konferenzzur UnterstutzungdesArbeitsprozessesmit SCA3Ddurchgefuhrt. Kommunikationvon BenutzernwahrendderverteiltenArbeit mit 3D Dokumentenist ein wichtigesHilfmittel, dasdie wirkungs-volle Durchfuhrungvon kooperativenKonferenzenuberComputernetzemoglichmacht.

Die SCA3D-Architekturerfullt alle genanntenAnforderungenund verfugt durchdenkombi-niertenAnsatzvon lokaler und Remote-Visualisierunguber ein hohesMaß an Flexibilit at beimkooperativen Arbeitenmit 3D Dokumenten.Der Begriff des3D Dokumentesin verteiltenUmge-bungenstehtdabeiim Mittelpunkt und wurdebei der Entwicklungder ArchitekturalswichtigsteOrientierungverwendet.

Beispieleineskooperativen Arbeitsprozesses

Als praktischesBeispielsoll nun einekooperative KonferenzzweierBenutzeranhandvon Test-ergebnissenbeschriebenwerden,bei derein 3D Dokumentmit einemCAD-KugellagermodellauseinzelnenKomponentenzusammengebautwerdensoll.Als Ausgangssituationwerdenzwei3D Do-kumentebereitgestellt,die zum einendasKugellagermodellund zum andereneineModell einerAchseenthalten.DasKugellagerist anfangsnochnicht zusammengebaut,sondernliegt in Formvon aneinandergereihter Einzelteilevor. Die beiden3D DokumentezusammenhabeneineGroßevon ungefahrzwei MByte undliegenauf demServer im Filesystembereit.In Abbildung9.8 sinddie Ausgangsdokumentegezeigt,die von zwei Benutzernmit Hilfe desPrototypender SCA3D-Architektur zusammengefugt werdensollen.Die Einzelteileder 3D Modelle liegen im OriginalalsparametrischeBasisobjekteund3D Netzevor, wobeiOpenInventor-IndexedFaceSet-KnotenzurgraphischenReprasentationder3D Netzeverwendetwurden.

Die Aufgabefur zwei Benutzer, die sichmit ihrenRechnernangetrenntenOrtenbefindenunduberein Netzmit demSCA3D-Server verbundensind,bestehtdarin,ein Gesamtdokumentzu er-zeugen,dasdaszusammengesetzteKugellagermit der eingefugtenAchseenthalt und am Serverabgelegt wird. DabeidurfendiebeidenBenutzerentsprechendeihrerAnbindungundLeistungOb-jektreprasentationen der einzelnenObjektein ihren jeweiligen Interaktionraumladen.Allerdingssollendie Benutzerversuchen,moglichstwenigeObjektein hoherAuflosunglokal zu verwenden,


Abbildung9.8:Ausgangsdokumentefur diekooperative 3D Konferenz.

umdieLastfur dasNetzunddie lokalenRechnermoglichstgeringzuhalten.

Abbildung9.9:ScreenshoteinerSCA3D-Client-AnwendungenwahrenddesArbeitsprozesses.

Die Aufgabewird hier soerledigt,daßbeideBenutzeranfangsdasKugellagerdokumentdurchRemote-Renderingvisualisierenund ein BenutzernachAbsprachedasAchsenobjektin dasDo-kumenteinfugt. Dannbearbeitetein Benutzerdie Positionder Achseund der außerenKugella-gerschale,wahrendder zweiteTeilnehmerdie beideninnerenKugellagerschalenbearbeitet.DieKugeln(3D Netze),die einzelnpositioniertwerdenmußten,bleibenbei demArbeitsprozeßun-verandert.Um die innerenTeile desKuglelagerszusammenzubauenzu konnen,aktiviert Benutzer� diesebeidenObjekteundverschiebtsieso,daßsie innerhalbderGruppederKugelneingepaßtsind. Benutzer � aktiviert inzwischendie außereSchaleund die Achseund bringt beidedurchVerschiebender Achsein die richtige relative Position.Dannaktiviert er nachdemBenutzereinsseineArbeit beendethat,eineinnereKugellagerschaleund positioniertAchseund außereSchale


Abbildung9.10:ScreenshotderClient-AnwendungendesanderenTeilnehmersnachFertigstellungdesDokumentes.

mit Hilfe derinnerenSchalerichtig. Am EndedesArbeitsprozessesist dasKugellagerzusammen-gefugt und die Achsean der richtigenStelleeingebaut,wobei beideBenutzermit relativ weniggeometrischerInformation in ihrer lokalen Szenenausgekommensind. Dadurchlassensich diezu ubertragendeDatenmengeund die lokaleLastmoglichstgeringhaltenund Teile, die nicht alsOriginal ubertragenwerdendurfen,werdenvor unkontrollierterWeiterverbreitunggeschutzt. AlsletztenArbeitsschrittdeaktivierendie Benutzeralle ObjekteundspeicherndasfertigeDokument,unterneuemNamenauf demServer ab. In denAbbildungen9.9 und 9.10 sind ScreenshotsderSCA3D-Client-Anwendungengezeigt,die wahrenddesbeschriebeneArbeitsprozessesvon beidenBenutzernaufgezeichnetwurden.Die gesperrtenBereichedesLoI-Reglerssind dabeidurcheinrote Einfarbung der Beschriftunggekennzeichnet.Die empfohlenenPositionendesReglerssinddurchdie Grenzenù & $*( und ù & $)( angegebenunddurcheinegruneEinfarbungkenntlichgemacht.Falls die Grenzenim gesperrtenBereichliegenwerdensiedementsprechendrot eingefarbt (sieheAbbildung9.9).Abbildung9.10zeigtdasfertige3D DokumentnachBearbeitungdurchdiebeidenTeilnehmerderKonferenz.

9.5 Zusammenfassung

In diesemKapitelwurdealszweiterwichtigerAspektderSCA3D-Architekturdaskooperative Ar-beitenmit 3D Dokumentenuntersucht.Dazuwurdendie AnforderungenanverteilteSystemefurkooperative Konferenzenbeschrieben,bei denenMehrbenutzervisualisierung von 3D Szenenver-wendetwird. EswurdenBasisanforderungen,wie Cut-and-Pastevon Objekten,Objektsynchroni-sationundBenutzerkommunikation,undfortgeschritteneAnforderungen,wie Adaptivitat desVer-haltensundSicherheitsmanagement,definiert.Dannwurdenkooperative Szenarieninnerhalbeines


SCA3D-Systemsdiskutiertund derNutzenvon Navigationsraumund Interaktionsraumenfur daskooperative Arbeitenausgewertet.Moglichkeiten zur Benutzerfuhrungdurch Informationsvisua-lisierung,die im SCA3D-Prototypenumgesetztsind, wurdenebenfalls vorgestellt.Im folgendenwurdendie AnsatzezurRealisierungderZugriffstransparenzundzurSynchronisationderObjektein Navigations-undIntaktionsraumenim einzelnenuntersucht.Dabeiwurdedie Realisierungvonstatischenund dynamischenSchnittstellenfur den Zugriff auf server-seitige3D DokumentemitHilfe desDocument-Request-Brokers nocheinmalgenauerbeleuchtet.AbschließendwurdenamBeispieleinerkooperativen Konferenzmit 3D DokumentenErgebnissevorgestellt,die mit HilfedesSCA3D-Prototypengewonnenwurden.Im nun folgendenAbschlußkapitelwird eineZusam-menfassungder Arbeit und ein Ausblick auf weitereForschungsarbeitenim ZusammenhangmitderSCA3D-Architekturgegeben.

Kapitel 10

Zusammenfassungund Ausblick

Als Abschlußwerdennundie Vorgehensweisebei derKonzeption,Umsetzungund Implementie-rungderSoftware-Architekturnocheinmalzusammengefaßtunddie erreichtenErgebnissebeiderBearbeitungdesThemasmit dengeplantenZielenverglichen.Die neuenAspekteim Hinblick aufdenStandderForschungaufdemGebietverteilterVisualisierungsarchitekturen sollennocheinmalherausgestelltwerden.WeiterfuhrendeForschungsrichtungenim Hinblick aufkombinierteVisuali-sierungsansatzefur 3D Dokumentein verteiltenUmgebungenwerdenalsAusblick angesprochen.Daruberhinaussoll die Erweiterbarkeit desKonzeptesauf heterogeneDokumente,die neben3DSzenenauchandereInhaltstypenwie Audio- oderVideodatenenthalten,angesprochenwerden.DieVerwendbarkeit von internaltionalenStandardszurRealisierungdesbeschriebenenKonzepteswirdebenfalls kurzdiskutiert.

10.1 Err eichteZiele und Schlußfolgerungen

DasArbeitsthemazielteaufdenEntwurfunddieUmsetzungeinerneuartigen,verteiltenSoftware-Architektur ab, die heutigenAnforderungenentsprechendintegrierte Moglichkeiten zum Mana-gementvon Komplexitat und der Sicherheitvon 3D Szenenbietet.Dabeisollte einedynamischeKombinationvon lokaler und Remote-Visualisierungvon 3D Szenenerlauben,einenoptimalenAusgleichderVerzogerungszeitbeimRemote-Renderingdurcheinehoheinteraktive Bildwieder-holratefur selektierteObjektezuerreichen,dielokal visualisiertwerden.Dadurchsollteesmoglichwerden,unterstutztdurchdasvisuellesFeedbackvoneinemDokument-undVisualisierungs-Servermit geschutztenundkomplexen 3D Szenenin verteiltenUmgebungenarbeitenzu konnen.Damitdie Randbedingungeneiner heterogenenUmgebung bezuglich Bandbreiteund lokaler LeistungeinzelnerClient-Anwendungenberucksichtigtwerden,sollte der Informationsgehaltauf Client-Seiteregulierbarsein,der zum Arbeitenmit 3D Szenenbenotigt wird. Dies wurdeals Level-of-Information-Ansatzbezeichnet.WeiterhinsollteeineTransparenzdesZugriffs aufverteilte3D Sze-nenrealisiertwerden,wofur einobjekt-orientiertesDokumentmodellfur 3D Szenenerfolgverspre-chendeinsetzbarist. Mit Hilfe dersogestaltetenSoftware-ArchitektursolltenVerfahrenrealisiertwerden,die eineadaptivesVerhaltenbezuglich der zu ubertragendenund lokal zu berechnendenDatenmengeermoglichenwurden.Außerdemsollteein KonzeptzumSicherheitsmanagementfur3D Szenenin der Architektur umgesetztwerden.Schließlichgehorte zu den Anforderungenanein solchesSystemauchdie Moglichkeit, daßmehrereBenutzersynchronisiertmit 3D SzeneninverteiltenUmgebungenarbeitenkonnen.Zusammengefaßtwar esalsodasZiel, eineverteilte,ko-operative Visualisierungsarchitektur fur 3D Szenenzu entwerfen,die besondersandenAspekten

165

KAPITEL 10. ZUSAMMENFASSUNGUND AUSBLICK 166

Komplexitat undSicherheitvon3D Szenenausgerichtetist.Mit diesenAnforderungenwurde daraufhindasKonzeptder SkalierbarenSzenenerarbeitet

und die Software-ArchitekturSCA3D entworfen. Ein Prototypfur dieseArchitektur wurdeent-wickelt und in einer Testumgebung ausgewertet. Die erreichtenZiele entsprechenden gestell-ten Anforderungen,was durch entsprechendeTestsund Meßergebnisseverdeutlichtwurde.Furdie Bearbeitungvon 3D Szenenwurdeder zentraleBegriff des3D Dokumentesverwendet,dasdurchseineEigenschaftenbesondersgut in denAufbau der beschriebenenSoftware-Architekturpaßt.Die technischeUmsetzungdesgefordertenSystemsgeschahdurch die EntwicklungeinesDocument-Request-Broker-Ansatzesfur verteilte3D Dokumente,die sichauf ein internesobjekt-orientiertesDokumentmodell,denSzenengraphen,abbildenlassen.DurchdiesenAnsatz,derdemKonzepteinerobjekt-orientiertenMiddleware,wie etwa demCORBA-Standard,ahnlichist, laßtsich die geforderteZugriffstransparenzfur verteilte3D Szenenrealisieren.Weiterhinwird durchdie VerwendungverschiedenergraphischerReprasentationsformenmit variablemImformations-gehalt,die als Proxy-Objekteder entferntenDokumentobjektebenutztwerden,der beschriebe-ne Level-of-Information-Ansatzrealisiert.Bei diesemAnsatzwird jederBenutzermit einemfurseineVerhaltnissegunstigenInformationgehaltversorgt und seineClient-Szenedementsprechendangepaßt.Dem Benutzerwird mit demLevel-of-Information-Schieberegler eineMoglichkeit zurKontrolle desInformationsgehaltin seinerlokalenSzenegegeben.Durch Austauschvon Objek-treprasentationenzwischenzwei synchronisiertenRendering-Pipelinesauf demServer- und demClient-Rechnerwird einedynamischenKombinationvon lokalemundRemote-Renderingerreicht.

Um ein adaptivesVerhaltenzu realisieren,wurdemit Hilfe einerPerformanzmetrikdie Steue-rungdesLevel-of-Information-Reglersundderlokalenbzw. Remote-Frameratenermoglicht.DiesePerformanzmetrikwertetsowohl dieAnbindungbandbreite, alsauchdielokaleLeistungderjeweili-genClient-AnwendungausundreagiertauchaufveranderlicheLeistungdesServers,daessichbeiderangewandtenTechnikum einenverteiltenRegelkreishandelt.Fur einenBenutzerbedeutetdieSteuerunguberdie Performanzmetrik,daßihm zu jederZeit ein BereichoptimalerPositionendesLoI-Reglersempfohlenwird unddementsprechendeinegeeignetePositionautomatischeingestelltwird. AllerdingskanneinBenutzervondieserEmpfehlungauchindividuell abweichen.Im Gegen-satzdazusindbestimmtePositionenderLoI-Skalafur denBenutzermit einervorgegebenenRechte-situationgesperrt.DiesegesperrtenBereichewerdenvondemintegriertenSicherheits-ManagementderSCA3DSoftware-Architekturfestgelegt undverhinderneineUbertragunggeschutzterObjek-treprasentationen.DasSicherheitskonzeptarbeitetmit einerAuthentifizierungderBenutzer, einemRollenkonzeptfur verschiedeneBenutzertypenundderTransformationvon3D Objektenin anderegraphischeReprasentationsformen.Durch Verhandlungvon RechtenzwischenClient und Serversoll demBenutzerdie Moglichkeit gegebenwerden,auchOriginaldatennachgeanderterRechte-situationzu erhalten.DieseRechtekonzeptlaßt sich im Bereichdigitaler Bibliotheken, bei demOriginalegeschutzt werdenmussen,oderim Bereichvon Produktschutzim Wirtschaftsumfelder-folgreicheinsetzen.

SchließlichwurdeauchdiegeforderteMehrbenutzertauglichkeit im EntwurfumgesetztundimPrototypderArchitekturrealisiert.MehrereBenutzerkonneninnerhalbderSCA3D-Architekturmit3D Dokumentenarbeiten,wobei jederTeilnehmermit einereigenenKonfigurationseinerClient-Szeneinteragiert.DadurchlaßtsichdasSystemandie Heterogenitat von verteiltenUmgebungenanpassenunddie VerzogerungzwischenungleichenClient-Anwendungenminimieren.Ein koope-rativesModell zumMehrbenutzerbetriebist BestandteilderSCA3D-Architektur. Zur Auswertungder beschriebenenKonzepteund Techniken wurdenTestlaufe in der dafur aufgebautenTestum-gebung durchgefuhrt und Meßergebnissegewonnen.DieseErgebnissewurdenvorgestelltund imHinblick aufdieAnforderungendiskutiert.


AusdieserZusammenfassungergebensichfolgendeneueAspekteim Hinblick aufdenaktuel-lenStandderForschungaufdemGebietderverteilten3D Visualisierungsarchitekturen:

� Verteilte3DDokumentealszentraleIdee: DurchEinfuhrungvon3DDokumentenalszentraleIdeebeimEntwurf und derEntwicklungeinerverteiltenVisualisierungsumgebung, werdendie Eigenschaftenvon digitalenDokumentenoptimalunterstutzt unddie Funktionalitat, dieein BenutzerbeimArbeitenmit Dokumentenerwartet,direkt in dasunterstutzendeSystemintegriert.

� Dynamische Kombinationvon verteiltenRendering-Pipelines: Durch den AustauschallerObjektreprasentationen, die innerhalbeinerRendering-Pipelineverarbeitetwerden,wird diedynamischeVerteilungvon Rendering-Prozessenermoglicht. Die Rendering-PipelinesaufServer- undClient-SeitewerdendabeiubereineMiddleware-SchnittstelleunddasStreamingvon Bilddatensynchronisiert.

� Entwurf eines Document-Request-Brokers: Die Ubertragung eines objekt-orientiertenMiddleware-Konzeptesauf3D Dokumentein verteiltenUmgebungen,wird durchdasobjekt-orientierteDokumentmodelleinesSzenengraphenoptimalunterstutzt. Die UmsetzungeinesDocument-Request-Brokers fur 3D Dokumenteist ein neuesKonzept,dasin dieserArbeitvorgestelltwird.

� Komplexitats- und Sicherheitsmanagementdurch den Level-of-Information-Ansatz: DurchdynamischeVerteilungvonObjektreprasentationen alsProxy-Objektedesentfernten3D Do-kumenteswerdensowohl Moglichkeiten fur den Umgangmit Komplexitat, als auchzumSchutzvon3D Dokumentenvor unkontrollierterVerbreitungbzw. Vervielfaltigungrealisiert.Der beschriebeneLevel-of-Information-AnsatzmachtdieseTechniken in verteiltenoffenenInformationsraumenmoglich.

10.2 WeiterfuhrendeArbeiten

Das Konzeptder SkalierbarenSzenenund die Software-ArchitekturSCA3D demonstrierendenEinsatzeineskombiniertenAnsatzesfur dasverteilteArbeitenmit 3D Dokumenten.Die 3D Do-kumentewerdendabeizwischenServer- und Client-Anwendungverteilt und sowohl entferntalsauchlokal visualisiert.Ein zentralerAspektist hierbeidie Verteilungund Unterstutzungvon be-liebigenObjektreprasentationen in derverteiltenUmgebung,wobeidie VerbindungzumOriginal-dokumentsolangewie notig aufrechterhaltenbleibt. Ein Ziel fur zukunftigeArbeitensolltedaherdieweitereIntegrationeinesmoglichstbreitenAngebotsvonObjektreprasentationensein.DerEin-satzvon und der UbergangzwischenparametrischenObjektenverschiedenerArt, 3D NetzenmitbeliebigerAuflosung,kombiniertenReprasentationsformenmittelsBounding-Box-undBilddatenundschließlich2D Bild- undKonturinformationsolltemoglichstkontinuierlichim Arbeitsprozeßstattfinden.Ein wichtigerPunkt,der dafur weiteruntersuchtwerdenmußte,ist die AnderungderverschiedenenObjektreprasentationenbei derAnwendungvon geometrischenManipulationen,sodaßein Originalobjektund seineReprasentationenin der Client-Szenemoglichst langeuberein-stimmen.Der Umweg ubereinevollstandigeAktualisierungdesClient-ObjektesdurchErzeugungeinerneuenObjektreprasentationamServer solltedabeinur in Ausnahmefallennotig werden,umdieBelastungvonServer-Rechner, NetzundClient-Rechnergeringzuhalten.Die AufspaltungderVerzogerungszeitin ihre Komponenten,die durchBildgenerierungam Server, Datenubertragung


undBildanzeigeamClient bestimmtwerden,undihre getrennteBerucksichtigungwarehier sinn-voll, um eineindividuelle Anpassungan die beteiligtenParameterwie Netzlast,Server-Last undClient-Lastzuerlauben.

Diesfuhrt direkt zu derForderungnacheffizienterenCodierungsverfahrenfur Bild- undGeo-metriedaten,die wahrenddesArbeitsprozessesubertragenwerdenmussen.Im RahmendieseAr-beit wurdensowohl Bildcodierverfahrender erstenGeneration(MPEG-1,H.263)alsauchsolchederzweitenGeneration(MPEG-4)getestetundin denverschiedenenPrototypenangewendet.DeraktuelleStandspeziellerVerfahrenzur Kompressionvon Geometriedatenwurdennur am Randeverfolgt. Zur effizientenUbertragungderbeschriebenenObjektreprasentationen solltederEinsatzdieserVerfahrenweiteruntersuchtwerden.InsbesondereKompressionsverfahren,die Objektinfor-mationenbeiderCodierungerhaltenundzurSteigerungdesKompressionsgradesverwenden,sindin diesemZusammenhangsehrinteressant.

AuchdieweitereAusarbeitungvon dynamischenSchnittstellenzubeliebigen3D Dokumentenist vielversprechend.Hierbeiist die automatischeErzeugungvon3D Toolsin derClient-SzenezurManipulationvon beliebigenParameternderDokumentobjektefur die praktischeAnwendungundeineguteBenutzerfuhrungbesondersinteressant.WenneinemBenutzerbei derBearbeitungeinesihm unbekannten3D Dokumentesdie passendenManipulationswerkzeuge im Augenblickder In-teraktionzur Verfugunggestelltwerden,wareeineErkundungdesDokumentesunddasVerstehendesInhaltessicherin verbesserterWeisemoglich. Auch die weitereDifferenzierungdesAufbausderClient-SzenedurchdenEinsatzmehrererProjektionsflachen,die in verschiedenerWeisekom-biniertwerdenkonnen,wurdediepraktischeEinsetzbarkeit desSystemserweitern.

Schließlichsolltemit Sichtauf die schnelleEntwicklungderTechnologieim Bereichderver-netztenInformationssystemeim Internetangestrebtwerden,einemoglichstweitreichendeVerbrei-tung und Einsetzbarkeit deshier beschriebenenSystemszu erreichen,indeminternationaleStan-dardsbei derUmsetzungverwendetwerden.Zur allgemeinenBeschreibungvon Dokumenten,uminhalts-basierteMerkmalewiederzugebenoderum auf entfernteObjektezuzugreifen,wird in denletztenJahrenaneinerVielzahlvon Standardsgearbeitet.Die wichtigstensind in diesemZusam-menhangder W3C StandardXML [GP01] zusammenmit demobjekt-orientierten Dokumentmo-dell DOM [DOM00], derISOStandardMPEG-7[ISO00a] zur inhalts-basiertenBeschreibungvonbeliebigenDokumentenundStandardszurRealisierungvonRemote-Procedure-CallsuberWWW-eigeneProtokolle, wie esetwadieSpezifikationXML-RPC[SJD01] oderderW3CStandardSOAP(SimpleObjectAccessProtocol) [See01] ermoglichen.Die ErweiterungdesKonzeptesauf allge-meineDokumente,die neben3D ObjektenauchAudio-, Video-,Bild- undTextobjekteenthalten,ist durchVerwendungdieserTechnologienfur zukunftige verteilte Informationssystemevielver-sprechend.UntersuchungenzurErweiterbarkeit desKonzeptesaufallgemeinedigitaleDokumentewarendaherfur zukunftigeArbeiteneinguterAnsatzpunktmit weitreichendenMoglichkeiten.

Literatur verzeichnis

[Alh98] Alhir, S.UML in a Nutshell, O’Reilly, ISBN 1-56592-448-7,1998

[AMD94] Ang, C.S.,Martin, D.C.,Doyle, M.D. IntegratedControl of DistributedVolumeVisuali-zationthroughtheWorld WideWeb, Proceedingsof IEEEVisualization94,1994

[Atk99] Atkinson,L. CorePHPprogramming:UsingPHPto Build DynamicWebSites, Markt undTechnik,ISBN: 013020787X,1999

[BB00] Benedens,O., Busch,C. Towards Blind Detectionof Robust Watermarksin PolygonalModelsComputerGraphicsForum,19(3)(Proceedingsof EUROGRAPHICS’00),2000

[BBH00] Borowski, M., Brocker, L., Heisterkamp,S.,Karajannis,A., Kolb, I., Loffler, J.ProDB-Projektdokumenteintelligentverwalten, ProceedingsDOAG’2000,DeutscheOracleAnwen-derKonferenz,pp.847-857,2000.

[BBL00] Borowski, M., Brocker, L., Heisterkamp,S.,Loffler, J.StructuringtheVisualContentofDigital LibrariesusingCBIRSystems, IEEE InternationalConferenceon InformationVisua-lization,2000

[BDG98] Brodlie,K.W., Duce,D.A., Gallop,J.R.,Wood,J.D.Distributedcooperative visualiza-tion, STAR: Stateof theArt Reports- Eurographics98.EurographicsAssociation,pp.27-50,1998

[Ben99] Benedens,O. Watermarkingof 3D-polygon-basedmodelswith robustnessagainstmeshsimplification, Proceedingsof SPIEConferenceonElectronicImaging‘99, SecurityandWa-termarkingof MultimediaContents,1999

[Bis00] Bissel,T., Bogen,M., Hadamschek,V., Riemann,C. Protectinga Museum’s Digital Stockthrough Watermarks, Proceedingsof the InternationalConferenceMuseumsand the Web2000,ISBN: I-885626-20-7,pp.73-82,2000

[BK96] Broll, W., Koop, T.: VRML: Today and Tomorrow, Computers& Graphics,Vol. 3(20).1996,pp.427-434,1996

[BMN99] Booch,G. , Martin, R. , Newkirk, J.W. Object-orientedAnalysisandDesignwith App-lications, AddisonWesley Longman, ISBN 0-201-89551-X,1999

[Cam98] Campagna,S.etal.EnhancingDigital DocumentsbyIncluding3D-Models, Computer&Graphics,Vol.22(6),pp.655-666,1998

[CC78] Catmull,E., Clark, J.H.RecursivelygeneratedB-splinesurfaceson arbitrary topologicalmeshes, ComputerAidedDesign,10,pp.350-355,1978

169

LITERATURVERZEICHNIS 170

[CCE98] Carraro,G.,Cortes,M., Edmark,J.,Ensor, J.ThePelotonBicyclingSimulator, 3rdSym-posiumon theVirtual RealityModelingLanguageVRML98, ACM SIGGRAPH,1998

[CDK94] Coulouris,G., Dollimore, J., Kindberg, T. Distributed systemsconceptsand design,Addison-Wesley (Internationalcomputerscienceseries),ISBN 0-201-62433-8,1994

[CH93] Carlsson,C., Hagsand,O. DIVE- A Platformfor Multi-User Virtual Environments, Com-puter& Graphics,Vol.7(6),pp.663-669,1993

[CHRS98] Christiansen,A., Hoding,M., Rautenstrauch,C.,Saake,G.Oracle8- effizienteinsetzen,Addison-Wesley, ISBN 03-8273-1347-3,1998

[CWH00] Campione,M. , Walrath,K. , Huml, A. TheJavatutorial: a shortcourseon thebasics,Addison-Wesley (TheJava series),ISBN 0-201-70393-9,2000

[Del99] Del Bimbo, A. Visual Information Retrieval, Morgan KaufmannPublishers,ISBN 1-55860-624-6,1999

[Die01] Diehl, S.DistributedVirtual Worlds, Springer-Verlag,ISBN 3-540-67624-4,2001

[Dit00] Dittmann,J.Digitale Wasserzeichen, SpringerVerlag,ISBN 3-540-66661-3,2000

[DOM00] DOM (W3C) Document Object Model (DOM) Level 2 Core Specification,W3C (World Wide Web Consortium) Document Object Model Level 2. Available athttp://www.w3.org/TR/DOM-Level-2-Core

[DSS99] Dittmann,J., Steinmetz,A., Steinmetz,R. Content-basedDigital Signature for MotionPicturesAuthenticationand Content-Fragile Watermarking, IEEE MultimediaSystems’99,Int. ConferenceonMultimediaComputingandSystems,Vol. 1, pp.209- 213,ISBN 0-7695-0253-9,1999.

[EF00] Enders,A., Fellner, D.W. Digitale Bibliotheken: Informatik-Losungen fur globale Wis-sensmarkte, dpunkt-Verlag,ISBN 3-932588-77-0,2000

[EHTE00] Engel,K., Hastreiter, P., Tomandl,B., Eberhardt,K. andErtl, T. CombiningLocal andRemoteVisualizationTechniquesfor InteractiveVolumeRenderingin MedicalApplications,In Procceedingsof IEEEVisualization’00 , pp.6-10,2000

[EK98] Ebrahimi,T., Kunt,M. Visualdatacompressionfor multimediaapplications, Proceedingsof theIEEE,Vol.86,No.6,1109-1125,1998

[ES98] Effelsberg, W., Steinmetz,R. Video CompressionTechniques, dpunkt-Verlag, ISBN 3-920993-13-6,1998

[ESE99] Engel,K., Sommer, O., Ernst,C. and Ertl., T. Remote3D Visualizationusing Image-StreamingTechniques, In Advancesin IntelligentComputingandMultimediaSystems(ISI-MADE ’99) , pp.91-96,1999

[FDFH90] Foley, J.,vanDam,A., Feiner, S.,Hughes,J.ComputerGraphics:PrinciplesandPrac-tice, SecondEdition, Addison-Wesley, Reading,Massachusetts,ISBN 0-201-84840-6,1990

[FH97] Fellner, D.W., Hopp,A. MRT-VR Multi-User Virtual Environment, Proceedingsof AAA97,1997


[FHM98] Fellner, D.W., Havemann,S., Muller, G. Modelingof and Navigationin complex 3DDocuments, Computer& Graphics,Vol.22(6),pp.647-653,1998

[FKK96] Freier, A., Karlton, P. andKocher, P. TheSSL3.0 Protocol, NetscapeCommunicationsCorporation,1996.

[FZ99] Fellner, D.W., Zens,M. ManagementandWorkflowof Electronic Documentsusinga 2nd-GenerationWWW-Server, ProceedingsWebNet99,pp.354-359,1999

[GFG98] Goebbels,G., Fournier, N., Gobel,M. et al. RemoteVisualizationof Radiological Dataona ResponsiveWorkbench, In Proceedingsof CARS’99, ComputerAssistedRadiologyandSurgery, 1999

[Gla84] Glassner, A. Spacesubdivisionfor for fast ray tracing, IEEE ComputerGraphicsandApllications,Vol.4 (10),pp.15-22,1994

[Gla99] Glassner, A. Principlesof Digital Image Synthesis, Vol.2: 987-1052,MorganKaufmannPublishers,ISBN 1-55860-276-3,1999

[GLG00] Goebbels,G., Lalioti, V., Gobel,M. On Collaboration in DistributedVirtual Environ-ments, In TheJournalof ThreeDimensionalImages,Japan,Vol.14(4),12,2000

[GP01] Goldfarb,C.,Prescod,P. TheXML handbook, Prentice-Hall,ISBN 0-13-055068-X,2001

[Gro98] Gross,M.H., Kobbelt,L. et al. Hierarchical Methodsfor ComputerGraphics, Eurogra-phics’98, Lisbon,EGTutorialNotes,1998

[GTGB84] Goral, C., Torrance,K., Greenberg, D. andBattaile,B. Modelling the interaction oflight betweendiffusesurfaces, ComputerGraphics(ProceedingsSiggraph’84), Vol.18(3),pp.213-222,1984

[HCF97] Hamilton,G. , Cattell,R. , Fisher, M. JDBCdatabaseaccesswith Java: a tutorial andannotatedreferenceAddison-Wesley (TheJava series),ISBN 0-201-30995-5,1997

[HEG98] Hartung,F., Eisert,P., Girod, B. Digital Watermarkingof MPEG-4Facial AnimationParameters, In Computer& Graphics,Vol. 22(4),pp.425-435,1998

[HG00] Hubeli,A., Gross,M. A survey of SurfaceRepresentationsfor GeometricModeling, Tech-nicalReport,ETH Zurich,2000

[HH95] Hartung,F., Horn,U. Codierungdigitaler Videosignalenach demMPEG-Standard, Digi-taltechnik,Bd. 9, Heft 1, 18-23,1995.

[HJT98] Haulsen,I., Jung,T., Tuchtenhagen,D. RemoteControl of Virtual EnvironmentsUsingImageStreams, Proceedingsof SecondIMA ConferenceonImageProcessing,Leicester, Uni-tedKingdom,1998

[HM90] Haber, R.B. andMcNabb,D.A. VisualizationIdioms:A ConceptualModel for ScientificVisualizationSystems, Visualizationin ScientificComputing, IEEEComputerSocietyPress,pp.74-93,1990

[Hop96] Hoppe,H. Progressivemeshes, ComputerGraphics(SIGGRAPH1996Proceedings),pa-ges99-108,1996


[HS98] Hesina,G.,Schmalstieg, D. A NetworkArchitecture for RemoteRendering, Proceedingsof2ndInternationalWorkshoponDistributedInteractiveSimulationandRealTimeApplications(DIS-RT’98), pp.88-91,1998.

[HS00] Heuer, A., Saake,G. Datenbanken: KonzepteundSprachen, InternationalThomsonPress,ISBN 3-8266-0619-1,2000

[HSF99] Hesina,G., Schmalstieg, D., Fuhrmann,A., Purgathofer, W. DistributedOpenInventor:A PracticalApproach to Distributed3D Graphics, Proceedingsof ACM Virtual RealitySoft-ware& Technology’99 (VRST’99),pp.74-81,London,1999.

[ISO99a] ISO/IEC MPEG-4: Coding of audio-visualObjects, ISO/IEC InternationalStandards14496,Parts1-6,1999

[ISO00a] ISO/IECOverview of the MPEG-7Standard, ISO/IEC JTC1/SC29/WG11N3445,Ge-neva,May/June,2000

[Jac92] Jacobson,I. et al. Object-orientedSoftware Engineering:A UseCaseDriven Approach,ISBN 0-201-54435-0,Addison-Wesley, 1992

[KP00] Katzenbeisser, S.,Petitcolas,F. InformationHiding techniquesfor stenographyanddigitalwatermarking, ArtechHousecomputinglibrary, ISBN 1-58053-035-4,2000

[Kum96] Kumar, V. MBone:InteractiveMultimediaontheInternet, New RidersPublishing,ISBN1-56205-397-3,1996

[LBS98] Lewis,G.,Barber, S.,Siegel,E.Programmingwith JavaIDL, Wiley , ISBN 0-471-24797-9, 1998

[LeG92] Le Gall, D.J.TheMPEGvideocompressionalgorithm, SignalProcessing:ImageCom-munication,Vol.4,No.4,129-140,1992

[Lev00] Levoy, M. etal. TheDigital Michelangelo Project:3D Scanningof Large StatuesProcee-dingsof SIGGRAPH’2000,2000

[LF01] Loffler, J. and Fellner, D.W. AdaptiveVisualizationof distributed 3D DocumentsusingImage Streaming Techniques, Springer (Wien), Proceedingsof EurographicsMultimediaWorkshop2001(ManchesterUK), ISBN 3-211-83769-8,2001

[LFe01] Loffler, J. andFellner, D.W. A Software Architecture for AdaptiveVisualizationof Dis-tributed3D Documentsin OpenInformationSpaces, Proceedingsof Cast’01,Conferenceonartistic,culturalandscientificaspectsof experimentalmediaspaces,Germany, 2001

[LHG97] Larkin,S.,Hewitt, W.T., Grant,A.J.SystemsandArchitecturesfor Visualization, Procee-dingsfrom the1997CERNSchoolof Computing,Prague,CzechRepublic,1997.

[Lia99] Liang, S. Java NativeInterface:programmer’s guideand specification, AddisonWesleyLongman(Java Series),ISBN 0-201-32577-2,1999

[Loe00a] Loffler, J.Object-basedImage Codingfor Cooperative3D Visualization, ProceedingsofInternationalConferenceon ComputerGraphics,VisualizationandInteractive Digital Media(WSCG2000),ISBN 80-7082-612-6,pp.197-203,2000.


[Loe00b] Loffler, J.Content-basedRetrieval of 3D Modelsin DistributedWebDatabasesbyVisualShapeInformation, Proceedingsof IEEE InternationalConferenceon InformationVisualiza-tion (IV 2000),pp.82-87,London,2000.

[Loop87] Loop, C.T. SmoothSubdivisionSurfacesBasedon Triangles, PhD Thesis,Departmentof Mathematics,Universityof Utah,1987

[Lyn97] Lynch,C. TheZ39.50InformationRetrieval Standard. Part 1, A Strategic View of Its Past,PresentandFuture, In D-Lib Magazine(online),April, 1997

[MB94] Macedonia,M., Brutzmann,D. MBONE,the MulticastBackbone, IEEE Computer, Vol.27(4),pp.30-36,1994

[MCB98] Miller, M., Cox, I., Bloom, J. Watermarkingin thereal world: an applicationto DVD,WorkshopSecurityIssuesin MultimediaSystems,Proceedingsof IEEEMultimediaSystemsConference’98, 1998

[MCO97] Mann,Y., Cohen-Or, D. SelectivePixel Transmissionfor Navigatingin RemoteVirtualEnvironments, Proceedingsof EUROGRAPHICS’1997Conference,Vol.16,No. 3, 1997

[MF99] Muller, G., Fellner, D.W. Hybrid SceneStructuringwith Applicationto RayTracing, Pro-ceedingsof InternationalConferenceonVisualComputing(ICVC’99), pp.19-26,Goa,India,1999

[MH00] Muller, K., Havemann,S..SubdivisionSurfacesTessellationon theFly usinga versatileMeshData Structure, Proceedingsof EUROGRAPHICS’2000Conference,Vol.19, No. 3,2000

[NN85] Nishita,T. andNakamae,E. Continuoustonerepresentationof three-dimensionalobjectstaking accountof shadowsand interreflection, ComputerGraphics(ProceedingsSiggraph’85), Vol.19(3),pp.23-30,1985

[NQ98] Nahrstedt,K., Qiao,L. Multimedia-secure Gateway, WorkshopSecurityIssuesin Multi-mediaSystems,in Proceedingsod IEEEMultimediaSystemsConferenceIMCMS’98, 1998

[OMA98] Ohbuchi, R., Masuda,M., Aono, M. WatermarkingThree-dimensionalPolygonalMo-delsthroughGeometricandTopological Modifications, Proceedingsof IEEE Journalon Se-lectedAreasin Communications,pp.551-560,1998

[OMG98] ObjectManagementGroup(OMG) TheCommonObjectRequestBroker: ArchitectureandSpecification, Revision2.3,1998

[Ora99] Oracle8i Visual InformationRetrieval User’s Guideand Reference, Oracle8.1.5Docu-mentation,1999

[Pho75] Phong,B.-T. Illuminationfor computergeneratedpictures, Communicationsof theACM,Vol.18(6),pp.311-317,1975

[PR99] Paquet,E., Rioux, M. The MPEG-7 Standard and the Content-based-Management ofThree-dimensionalData: A CaseStudy, InternationalConferenceon MultimediaComputingandSystems:375-380,1999


[PR01] Puder, A., Romer, K. Middleware fur verteilteSysteme, dpunkt-Verlag,ISBN 3-932588-03-7,2001

[RFC1521] BorensteinN. andFreed,N. MIME (MultipurposeInternetMail Extensions)Part One:Mechanismsfor SpecifyingandDescribingtheFormatof InternetMessageBodies, RFC1521,1993.

[RFC2616] FieldingR. etal. Hypertext TransferProtocol- HTTP/1.1, RFC2616,1999

[RFL98] Rantzau,D.,Frank,K., Lang,U.,Rainer, D., Wossner, U. COVISEin theCUBE:AnEnvi-ronmentfor AnalyzingLargeandComplex SimulationData, Proceedingsof the2ndWorkshopon ImmersiveProjectionTechnology(IPT ’98), 1998

[RMW98] Rzepa,H. S., Murray-Rust,P. andWhitaker, B. J. TheApplicationof ChemicalMul-tipurposeInternetMail Extensions(ChemicalMIME) InternetStandards to Electronic MailandWorld-Wide Webinformationexchange, Journalof ChemicalInformationandComputerSciences,Vol.38,976-982,1998

[RR97] Riley, M., Richardson,I. Digital videocommunicationsArtech House, ISBN 0-89006-890-9,1997

[Sch00] Schafer, S.EfficientObject-BasedHierarchical RadiosityMethods, DissertationamFach-bereichMathematikundInformatikderTechnischenUniversitat Braunscheig,2000

[SG96] Schmalstieg, D., Gervautz, M. Demand-DrivenGeometryTransmissionfor Distribu-ted Virtual EnvironmentsComputerGraphicsForum, 15, 3 (Proceedingsof EUROGRA-PHICS’96,Poitier, France),pp.421-433,1996

[See01] Seely, S.SOAP: crossplattform, Prentice-Hall,ISBN 0-13-090763-4,2001

[Sieg96] Siegel,J.CORBA: fundamentalsandprogramming, New York,N.Y. (u.a.): Wiley , 1996.- XXVI, ISBN 0-471-12148-7,1996

[Sik97] Sikora,T. TheMPEG-4VideoStandard VerificationModel, IEEETransactionsoncircuitsandsystemsfor videotechnology, Vol.7(1),19-31,1997

[SJD01] SaintLaurent,S., Johnston,J., Dumbill, E. Programmingwebserviceswith XML-RPC,O’Reilly Verlag,ISBN 0-596-00119-3,2001

[SRD98] Sowizral, H. , Rushforth,K. , Deering,M. The Java 3D API specification, Addison-Wesley , ISBN 0-201-32576-4,1998

[SSNM97] Schmidt,J.W., Schroder, G. et al. Linguisticandarchitectural requirementsfor perso-nalizeddigital libraries, Int. J.of Digital Libraries1, 1, 89-104,1997

[Stei00] Steinmetz, R. Multimedia-Technologie: Grundlagen, Komponentenund Systeme,Springer-Verlag,ISBN 3-540-67332-6,2000

[SZ99] Singhal, S., Zyda, M. Networked Virtual Environments:Design and Implementation,Addison-Wesley, ISBN 0-201-32557-8,1999


[VY99] Vaysburd, A. andYajnik, S. Exactly-OnceEnd-to-EndSemanticsin CORBA InvocationsAcrossHeterogeneousFault-Tolerant ORBs, Proceedingsof 18th IEEE SymposiumOn Re-liableDistributedSystems,pp.296-297,1999

[Wah98] Wahl,G.UML kompakt, ZeitschriftOBJEKTspektrum2/98,101CommunicationsVerlag,1998

[War94] Ward, G.J. The RADIANCElighting simulationand renderingsystem, ComputerGra-phics,Proceedingsof SIGGRAPH‘94,459-472,1994

[Wer98] Wernecke, J. The Inventor Mentor - ProgrammingObject-Oriented3D GraphicswithOpenInventor, AddissonWesley, ISBN 0-201-62495-8,1998

[Whi98] Whitted,T. An improvedillumination modelfor shadeddisplay, Communicationsof theACM, Vol.23,No.6,pp.343-349,1980

[WKL98] Weibel,S.,Kunze,J.,Lagoze,C. et al. Dublin Core metadatafor ResourceDiscovery,IETF InformationalRFC,(http://www.ietf.org/rfc/rfc2413.txt), 1998

[WK96] White, J.S.,andKlaphaakD.T. Using Java and OpenInventor to RapidPrototype3DWorlds, Proceedingsof 3D andMultimediaon theInternet,WWW andNetworks,Bradford,UK, 1996

[WWB96] Wood,J., Wright, H., Brodlie, K. Visualizationover the WWWand its applicationtoenvironmentaldata, Proceedingsof IEEEVisualization96,pp.81-92,1996.

[YC98] Yi, J.,Chelberg, D. Model-based3D ObjectRecognition UsingBayesianIndexing, Com-puterVisionandImageUnderstanding,Vol.69,No.1:87-105,1998