Det Virtuelle Bibliotek

Afløsningsopgave for studieprogrammet Virtual Reality


DØK-overbygningen (cand.merc.dat.)
Handelshøjskolen i København
15. september 1995


Skrevet af:
Thomas Hensing ( thomas@hensing.dk )
Søren Tjørnov ( soren@tjornov.dk )
Birger Larsen ( birgerl@inet.uni-c.dk )
Thomas Rasmussen

Sidst opdateret den 16. april 1998


Indholdsfortegnelse

1. Forord

2. Indledning

3. Problemformulering og metode

4. Karakteristik af brugergrænseflader

5. Analyse af visualiseringsteknikker 6. Design 7. Tilpasset design 8. Beskrivelse af implementeringen 9. Test 10. Konklusion

11. Brugervejledning til Det virtuelle Bibliotek

12. Praktiske erfaringer

Bilag


1. Forord

Denne afløsningsopgave er skrevet af Birger Larsen, Thomas Rasmussen, Søren Tjørnov og Thomas Hensing i forbindelse med studieprogrammet "Virtual Reality". Studieprogrammet startede den 1. september 1994. Vejleder har været Jan Pries-Heje fra det daværende Institut for Anvendt Datalogi og Systemvidenskab.

Efter aftale med Jan Pries-Heje, er opgaven i vid udstrækning struktureret som klassisk datalogiopgave, som den kendes fra DØK-studiet. Den er opbygget i en række faser: Analyse, design, implementering og test. For at det skal være muligt at identificere hver enkelt studerendes arbejdsindsats i opgaven, har vi i bilag A angivet hvem der har skrevet hvilke afsnit, samt hvem der har ydet sekundær bistand.

Studieprogrammet har været opdelt i en teoretisk og en praktisk del. Den teoretiske del strakte sig fra 1. september 1994 til 8. marts 1995. I denne periode var gruppen på VR-konference i Hamborg, læste og præsenterede et bredt VR-pensum, samt skrev en artikel i samarbejde med Lone Malmborg og Jan Pries-Heje. Artiklen blev fremlagt af Lone Malmborg på konferencen IRIS ´95 i Århus, august 1995. Endvidere er der blevet bragt to artikler i månedsbladet Alt om Data om henholdsvis vores anvendte værktøj, WorldToolKit for Windows (juli 1995) og det praktiske resultat af studieprogrammet, VR-systemet "Det virtuelle Bibliotek" (september 1995).

Den praktiske del af studieprogrammet strakte sig fra den 20. marts til den 15. september 1995. Her blev selve VR-systemet designet, implementeret og testet. Samtidig blev denne afløsningsopgave skrevet.


2. Indledning

Der findes i dag mange forskellige bud på definitioner af VR. Dette forskningsområde er endnu så ungt, at der ikke har fundet en endegyldig begrebsafklaring sted. Vi vil i denne artikel benytte følgende definition: En VR brugergrænseflade er et fuldt omsluttende tredimensionelt, interaktivt grafisk miljø, der giver brugeren en illusion af at være tilstede i en kunstigt skabt virkelighed. Denne definition er inspireret af [Pimentel & Teixeira 1995].

VR har et stort anvendelsespotentiale indenfor en bred vifte af områder. Simulering, spil, design, indlæring og informationsrepræsentation er blot nogle af anvendelsesmulighederne. Vi vil starte med at kategorisere disse anvendelsesmuligheder i to hovedtyper: Simulations VR og ægte VR.

2.1 Simulations VR
Den første type bruger VR brugergrænsefladen til at skabe en slags kopiverden og heri vise situationer, objekter mv., der fysisk eksisterer i den virkelige verden og give brugeren mulighed for at at interagere med dem. Denne form for VR-anvendelse kalder vi simulations VR. Et eksempel herpå kan være en flysimulator til træning af piloter, der nøje efterligner et cockpits instrumenter, udsynet fra cockpittet, samt giver brugeren en række sanseoplevelser via lyd og bevægelse, som de forekommer i et rigtigt fly.

2.2 Ægte VR
Den anden anvendelsestype, som vi vil betegne ægte VR, adskiller sig fra simulations VR, ved at man heri netop forsøger at opbygge miljøer, objekter mv., der ikke har en direkte analog til virkelighedens verden. Man kan tage svært perciperbare og abstrakte begreber fra den virkelige verden med ind i denne type VR, og gøre dem mere konkrete og forståelige, ved at skabe en ny verden med en anderledes og selvstændig virkelighed. Eksempelvis kan man tage et matematisk udtryk fra virkeligheden, og omforme det til en tredimensional animation i ægte VR for at forklare betydningen. Herved bevæger man sig altså fra et abstrakt til et mere konkret repræsentationsniveau.

Hidtil har man først og fremmest set anvendelser af den første type. VR er da også en umiddelbar oplagt teknik til at simulere miljøer, der i den virkelige verden kan være for ressourcekrævende eller farlige at bevæge sig i. Samtidig opnår man ved simuleringer en stor frihedsgrad til at manipulere og kontrollere det simulerede. F.eks. anvendt til arkitektoniske formål, hvor man let kan rive det konstruerede ned, opbygge eller gendesigne nyt og se dette fra mange vinkler.

Årsagen til at simulations VR hidtil har været mest udbredt, skal måske findes i, at den kræver mindre fantasi end ægte VR. Det er velkendt indenfor medieforskningen, at man ofte har overført traditionelle og velkendte mediers udtryksformer til nye medier, og dette gælder også for VR. En parallel kan drages til filmmediet. Da spillefilmen kom til verdenen, overtog den i starten teatrets virkemidler. Først med tiden udvikledes og nuanceredes filmens udtryksformer og virkemidler. I dag kan meget af det, der er umuligt i virkeligheden, laves og vises på film. Man kan sige, at filmen har skabt sin egen virkelighed og dermed i sig selv udgør en slags VR.

Da VR brugergrænsefladen befinder sig i sin barndom, har den endnu ikke udviklet en selvstændig udtryksform, men har inddraget teknikker fra andre medier. F.eks. er der lavet VR-systemer, der, inspireret af en almindelig computers keyboard, giver brugeren inputmulighed vha. et virtuelt keyboard. Her ville talegenkendelse i stedet have været et mere naturligt og rigtigt udtryksmiddel for brugeren i VR-mediet (brugeren skal blot fortælle sine ønsker til et talegenkendelsessystem, i stedet for at stoppe op og bruge tid på at indtaste sine ønsker bogstav for bogstav på tastaturet).

Vi vil påstå, at fokus fremover, i langt højere grad end i dag, vil komme til at hvile på ægte VR, idet vi mener, at det er her VR brugergrænsefladens virkelige og uudforskede potentiale ligger. Især indenfor håndteringen af store informationsmængder.Et af de forhold, der taler herfor, er det, at der hos mange mennesker tilsyneladende er et stadigt stigende behov for at kunne håndtere store informationsmængder. Denne udvikling kan f.eks. illustreres af det hastigt voksende Internet. Det giver brugerne adgang til mange millioner gigabyte information, om alt mellem himmel og jord, placeret på computere spredt over hele kloden. VR kan muligvis anvendes til at hjælpe brugere til bedre at kunne overskue store informationsmængder.

Der findes i dag kun få eksempler på VR-systemer til håndtering af store informationsmængder. I [Hamit] beskrives en VR-markedsplads med finansielle instrumenter og papirportfolier. Heri er f.eks. aktier repræsenteret som objekter med firmalogo. Størrelsen på objekterne afhænger af aktiens pris, og objektets farve fortæller om prisen er på vej op eller ned.

Andre interessante metoder til informationsrepræsentation finder man i isualiseringsforskningen på Xerox PARC (Palo Alto Research Center). Denne tager dog ikke udgangspunkt i rigtig VR, men i en form for VR, man kalder desktop VR. Dybdeeffekten heri er begrænset og kan nødvendigvis ikke være ægte 3D, men snarere, hvad vi vil vælge at betegne som 2½D grafik. I [Robertson m.fl. 93] er beskrevet et system kaldet Information Visualizer, der indeholder en række informationsrepræsentationsmetoder. Disse metoder kan håndtere store og komplekse mængder af hierarkiske, lineære og rumlige data, der normalt er uoverskuelige og svært håndterbare ved brug af traditionelle 2D visualiseringsteknikker. Information Visualizer beskrives nærmere i afsnit 5.1, sammen med en række andre teoretiske og praktisk implementerede visualiseringsteknikker.

Det er vores antagelse, at VR brugergrænsefladen er velegnet til håndtering af store og komplekse informationsmængder. Udover de eksperimenter og anvendelser, der er beskrevet i denne rapport, vil vi substantivere denne antagelse ved at svare på nedenstående problemformulering.


3. Problemformulering og metode

I denne opgave vil vi forsøge at eftervise vores antagelse om, at en VR-brugergrænseflade er hensigtsmæssig til håndtering af store og komplekse informationsmængder. Dette vil vi gøre ved at gennemføre analyse, design og implementering af en VR brugergrænseflade til visualisering af, søgning i og manipulering med en stor og kompleks informationsmængde fra en konkret biblioteksdatabase over bøger, artikler, cd-rom'er mv. På baggrund af vores erfaringer med denne prototype håber vi at kunne sige noget generelt om VR-brugergrænsefladers anvendelighed.

For at kunne skelne mellem forskellige typer brugergrænseflader, vil vi indledningsvist diskutere VR i relation til andre typer brugergrænseflader, samt opbygge en referenceramme til at gruppere og karakterisere brugergrænseflader (kapitel 4).

Vores udgangspunkt for designet af vores system vil være en analyse af eksisterende VR-systemer (primært desktop VR) til informationshåndtering. Disse systemer vil vi kort beskrive og klassificere ud fra en række essentielle karakteristika. Vi vil derefter analysere hvilke krav, der skal stilles til et biblioteks-søgesystem. Hvilke data skal systemet indeholde, og hvilke søgemuligheder brugeren har behov for (kapitel 5).

Af de beskrevne teknikker vil vi udvælge dem, som efter vores mening er bedst egnet til vores problemstilling, og med dem som basis vil vi designe et 'optimalt' VR-bibliotekssystem, dvs. et system som ville kunne implementeres med nuværende state-of-the-art teknologi. Et sådant system vil vi naturligvis ikke have mulighed for selv at implementere, men overvejelserne om det vil give os et grundlag for at beslutte, hvilke aspekter af VR-brugergrænsefladen, vi bør koncentrere vores undersøgelser om (kapitel 6).

Når det optimale design er opstillet, vil vi tilpasse det vores tilgængelige teknologi og ressourcer, således at vi får designet et system, vi rent faktisk kan implementere. Nogle aspekter ved systemet vil få højere prioritet end andre, således at vi får brugt vore ressourcer mest hensigtsmæssigt (kapitel 7).

Implementeringen af systemet vil foregå som prototyping. Ingen af os har før prøvet at udvikle VR-applikationer, så i begyndelsen vil en stor del af tiden derfor gå med at udforske udviklingsmulighederne (kapitel 8).

Fordi der er tale om en prototype, vil vi koncentrere testen omkring brugerens oplevelse af systemet. Vi vil gennemføre tænke-højt forsøg med varierede opgaver for at få en indikation af, hvilke former for søgning, systemet egner sig bedst til, og hvilke former, der stadig varetages bedst af traditionelle bibliotekssystemer. Der ud over vil tænke-højt-testen blive suppleret af en ekstern test (kapitel 9).

På baggrund af testen vil vi konkludere, hvorvidt vores antagelse om VR-brugergrænsefladens anvendelighed til informationshåndtering holdt stik. I første omgang kan vi kun konkludere, i hvor høj grad vores mindre-end-optimale system er anvendeligt, men da systemet vil indeholde mange af det optimale systems elementer, skulle vi også kunne udtale os om det optimale systems anvendelighed. Endelig skulle vi gerne kunne udtale os generelt om VR-brugergrænsefladers anvendelighed (kapitel 10).

En del af vores opgave går ud på at undersøge, hvordan man i praksis udvikler et VR-system. Hvilken hardware og software skal bruges, og hvordan får man det til at spille sammen? Disse spørgsmål er vi forhåbentligt blevet klogere på efter endt implementering af systemet, og vi vil da opsamle de vigtigste erfaringer (kapitel 12).


4. Karakteristik af brugergrænseflader

For at nå frem til en forståelse for VR brugergrænsefladen og dens anvendelighed til visualisering af, søgning i og manipulering med information, vil vi i det følgende afsnit diskutere VR i relation til andre brugergrænseflader. Analysen tager udgangspunkt i begrebet inkorporation, der af [Kirkeby & Malmborg] introduceres som en referenceramme til at karakterisere og gruppere brugergrænseflader.

4.1 Inkorporation
Inkorporation defineres som den grad af nærhed, brugeren føler til den virkelighed, der opstår, ved den gensidige interaktion mellem systemet og brugeren via grænsefladen. Graden af inkorporation synes at afhænge af systemets evne til at formidle sanseindtryk til og modtage input fra brugeren. Primært afhænger det af de visuelle sanseindtryk, sekundært af de auditive, taktile, kinæstetiske, lugt og smagssanseindtryk.

Formidlingen af information kan ske i 1, 2 eller 3 dimensioner, hvor sidstnævnte medfører den højeste grad af inkorporation. [Kirkeby & Malmborg] inddeler eksisterende brugergrænseflader i nedenstående tre grupper med stigende grad af inkorporation:

  1. 1D Tegnbaseret, ikke grafisk grænseflade
  2. 2D Grafisk multimedia (audio/video) grænseflade
  3. 3D Grafisk syn-kinestetisk (multi-sensorisk) grænseflade

Gruppe A brugergrænseflader formidler udelukkende visuel information i form af lineære tekstsekvenser. Et eksempel på en gruppe A brugergrænseflade er operativsystemet DOS.

Gruppe B brugergrænseflader er baseret på en rumlig formidling af information, om end denne er begrænset til to dimensioner. Kendetegnende for denne gruppe er, at den visuelle informationsformidling sker gennem en blanding af diskursiv tekst, ikoner, billeder, video m.v. Endvidere inddrages ofte auditive virkemidler til at understøtte den visuelle informationsformidling. Et eksempel på en gruppe B brugergrænseflade er operativsystemet OS/2.

Gruppe C brugergrænseflader formidler en ægte rumlig afbildning i tre dimensioner. Denne gruppe brugergrænseflader betegnes som syn-kinestetiske fordi kroppen inddrages aktivt i sansningen af det afbildede. Dette sker ved at lade kropsbevægelser diktere perspektivet i afbildningen. Endvidere er denne gruppe kendetegnet ved at tilstræbe en multi-sensorisk informationformidling. Foruden visuel og auditiv informationsformidling anvendes ideelt taktile og kinestetiske sansepåvirkende enheder til at formidle berøringssensationer og force-feedback (force-feedback i VR sammenhæng vil sige at kontakt med virtuelle objekter resulterer i en fysisk berøringssensation hos brugeren). Et eksempel på en gruppe C brugergrænseflade er et VR system som divisions dVISE (et meget udbredt VR udviklingsværktøj).

4.2 Multimedia brugergrænsefladen
Den stadig mere udbredte multimedia (MM) brugergrænseflade er et eksempel på en gruppe B brugergrænseflade. Her formidles ved hjælp af to-dimensionel grafik visuelle informationer. Graden af inkorporation er i MM grænsefladen højere end for tegnbaserede gruppe A systemer. Primært fordi MM grænsefladen, foruden at kunne formidle abstrakt symbolsk og tekstuel information, også kan formidle ikonisk information som billeder, video osv.

4.3 VR brugergrænsefladen
Mens MM brugergrænsefladen fremstår som en grænseflade, der kræver en vis tilvænning hos brugeren, tilstræber VR at skabe en brugergrænseflade, der ikke kræver, at brugeren tilegner sig en specialiseret kommunikationsform for at interagere med systemet. Det forsøges opnået ved at skabe en så høj grad af inkorporation som muligt for brugeren. VR er en gruppe C brugergrænseflade.

VR brugergrænsefladens evne til at inkorporere brugeren i den virkelighed den formidler, skabes for det første ved, at den visuelle afbildning er en fuldt omsluttende syn-kinestetisk rumlig afbildning. Den distance, der eksisterer i MM brugergrænsefladen, mellem bruger og system, er tilsyneladende forsvundet i VR. Brugeren føler sig omsluttet af den virkelighed som systemet formidler, fordi den visuelle afbildning udfylder hele brugerens synsfelt og i real-tid tilpasser billedet efter brugerens bevægelser.

Medvirkende til at inkorporere brugeren yderligere i den virtuelle verden er anvendelsen af taktile og kinestetiske sanseindtryk, som supplement til de visuelle og auditive sanseindtryk. Afbildede objekter kan således berøres, fastholdes og endog give force-feedback. Når alle disse sansninger spiller sammen, er der tale om en synkinestetisk grænseflade.

Selvom både MM og VR brugergrænsefladen tillader fri brugeraktion, adskiller VR sig også på dette punkt væsentligt fra MM brugergrænsefladen. Brugerens aktioner foregår nu ikke længere gennem specialiserede kommunikations-instrumenter som tastatur og mus, men gennem naturlige kommunikationsmidler som kropsbevægelser, gestik og tale.

4.4 Desktop VR
Desktop VR er en hybrid brugergrænseflade, der indeholder træk fra både 2D gruppe B og 3D gruppe C brugergrænseflader. Af samme grund benævnes desktop VR ofte som en 2½D brugergrænseflade. Desktop VR er som rigtig VR en rumlig 3D afbildning. Objekter kan betragtes fra alle synsvinkler og brugeren kan navigere frit mellem informationer. Men hvor rigtig VR formidler den visuelle information gennem et omsluttende Head-Mounted-Display (HMD), afbildes desktop VR, som navnet antyder, på en almindelig computerskærm. Perspektivet i afbildningen dikteres ikke af kroppens bevægelser, men i stedet af et input-device som f.eks. en mus, et joystick eller specialiserede koder. Det betyder, at brugerens orientering i desktop VR bliver mindre naturlig end i rigtig VR. Den manglende omsluttethed bevirker, at man i desktop VR ikke fuldt ud føler sig placeret i en anden virkelighed, og man opnår således ikke fuld inkorporerethed.

4.5 Design i VR vs. traditionel desktop VR
Ved implementering af informationsvisualisering i VR er der en række fordele og ulemper i forhold til en tilsvarende implementering i desktop VR. Disse aspekter er man nødt til at tage højde for når man designer et VR system. Den væsentligste forskel på desktop VRs 2½D grafik og VR´s omsluttende 3D grafik er, at visualiseringen i VR udgør hele synsfeltet, i modsætning til desktop VR, hvor visualiseringen kun er at finde i et udsnit af synsfeltet, nemlig computerskærmen. Det fulde synsfelt giver en bedre rumfornemmelse og samtidig en bedre orienteringsevne, fordi man hele tiden ser omgivelserne til det aktuelle fokus. Endelig kan man i VR, pga. det øgede synsfelt og det større arbejdsområde, repræsentere en større mængde information end i desktop VR grafik.

Ved desktop VR kan man let afbryde opmærksomheden overfor hvad der sker på skærmen ved en bevægelse med øjnene. Det kan man ikke i omsluttende VR, hvilket gør, at brugeren ikke har muligheden for at lade sin interesse falde på et objekt udenfor grænsefladen for et kort øjeblik, for derefter at vende tilbage.

For at bevare illusionen om at være i en anden virkelighed, skal så mange sanser som muligt stimuleres i en så overbevisende grad som muligt, samt at holde den egentlige virkelighed udenfor VR-systemet usynlig, uhørlig osv. For en række sanser er dette i dag ikke teknisk muligt, hvorfor graden af inkorporation nedsættes. Et eksempel herpå er at give realistisk force-feedback (fysisk følelig modstand). ved kontakt med objekter. Hvis ressourcer eller tekniske muligheder er begrænsede, skal man prioritere påvirkning af sanser efter deres betydning for graden af inkorporation. Dvs. den visuelle sans over de øvrige. Et fuldt omsluttende VR system inddrager brugerens visuelle sans fuldstændig.

VR kan give både nogle problemer, idet alle input enheder, så som mus, tastatur eller dataglove, ikke længere er synlige i forhold til desktop VR. Et løsning på dette kan være at indbygge virtuelle input devices, som f.eks. et virtuelt tastatur. I stedet for på denne måde at inddrage virkemidler fra tidligere medier, bør man dog løse dette med bedre udtryksmedier, f.eks. via talegenkendelse. En væsentlig forskel på desktop VR og VR er, at man kan foretage alle former for objektmanipulation som er kendt fra den virkelige verden, forudsat de er defineret i systemet.

At navigere i VR vil sige at ændre point-of-view (en samlet betegnelse for udsyn og retning). Hvad man ser i sit point-of-view afhænger af dets position og orientering. Orientering af point-of-view afgører synsretningen og er givet ved de tre variable pitch (op/ned om x-aksen), yaw (venstre/højre om y-aksen) og roll (rotering venstre/højre om z-aksen).

Det er også lettere at skifte point-of-view, idet kroppens bevægelser fungerer som input device. Man drejer blot hovedet, eller læner kroppen frem, hvorved der er øjeblikkelig respons i hele synsfeltet. Herved stiger graden af inkorporation. I desktop VR skal man f.eks. med en musepeger på nogle trykknapper angive, hvorledes man ønsker point-of-view skal ændre sig.

Orienteringsevnen er mere intuitiv i VR, idet hele kroppen og alle dens sanser bruges som input device (bemærk, at orienteringsevne ikke er det samme som orientering; orienteringsevne er evnen til at reetablere sit synsfelt). I desktop VR sker orienteringen udelukkende visuelt. En fare ved både desktop VR og VR er dog, at man kan miste orienteringen ved pludselige skift mellem scenarier. I begge tilfælde skyldes det en manglende oplevelse af tid og afstand mellem start- og slutposition, samt det mellemliggende rum. Dette kan i desktop VR modvirkes ved at inkludere et kort man kan orientere sig efter. Dette er sværere i VR, idet den manglende oplevelse afstandsoplevelse forstærkes af omsluttetheden.

Ved desktop VR sidder man blot på sin stol og skal ikke tage stilling til kroppens position, idet den ikke er en del af den kunstige virkelighed. I VR er hele kroppen inddraget, og er således en del af illusionen. Man er nødt til at tage stilling til hvordan den skal transporteres rundt, set i relation til at man bevarer orienteringen. Dette kan f.eks. gøres, ved at man lader sig transportere på et flyvende tæppe [Benedikt]. Angivelse af point-of-view kan ske vha. af gestik eller udtryksmidler indbygget i det flyvende tæppe.

De bevægelser man foretager sig i den virtuelle verden skal ses i relation til den fysiske verden. Hvis bevægelserne i den virtuelle verden er skaleret analogt ifht den fysiske verden, så vil det skabe et problem hvis flader, objekter ol. i den fysiske verden ikke stemmer overens med dem i den virtuelle. Dette kan løses f.eks. ved at lade brugeren bevæge sig indenfor et afgrænset rum i den virtuelle verden, som tilsvarer et rum i den fysiske verden. I den virtuelle verden kan brugeren dog portere mellem rummene, for at give en illusion af at der er mere end eet rum. På denne måde bliver han også i den fysiske verden altid inden for rummets grænser. [Jacobsen]. En anden løsning kan være at lade brugeren bevæge sig på en trædemølle [Hamit].


5. Analyse af visualiseringsteknikker

I dette afsnit vil vi beskrive udvalgte teknikker til visualisering af informationer. For hver teknik vil vi beskrive, hvorledes visualisering af, søgning i og manipulering med informationer foregår. Beskrivelserne er, med undtagelse af en enkelt, nemlig File System Navigator, udelukkende baseret på litteratur, idet vi ikke har haft mulighed for selv at prøve systemerne. Formålet med analysen af disse visualiseringsteknikker er, at vi kan inspireres af eller anvende disse i det efterfølgende design af vores VR-system.

5.1 Information Visualizer
Information Visualizer [Card m.fl.] er en samling af desktop VR visualiseringsteknikker udviklet på Xerox PARC. Systemet anvendes i praksis til bl.a. visualisering af organisationsplaner, filsystemer, kalendere og projektforløb.

Alle teknikkerne i Information Visualizer har de samme muligheder for bevægelse af brugerens point-of-view: Walking Metaphor og point-of-interest flight. Walking Metaphor betyder, at brugeren frit kan bevæge sig i det tredimensionale rum, mens point-of-interest-flight betyder, at brugeren vælger et punkt på et objekt og bliver fløjet direkte derhen.

5.1.1 Cone Trees
Cone Trees [Robertson m.fl. ´91] visualiserer hierarkisk strukturerede informationer af en vilkårlig type vha. et såkaldt kegletræ. Træet vises i 2½D grafik, hvorved træets grene får kegleform. De enkelte informationsobjekter vises som rektangler og er kun karakteriseret ved deres navn og deres position i hierarkiet. Teknikken kan visualisere relativt store mængder data (som eksempel nævnes et filsystem indeholdende ca. 10.000 filer), men kun ét hierarki af gangen kan betragtes.


Figur 1: Cone Trees

Brugeren kan udvælge et enkelt objekt, hvilket medfører at træet drejes, således at det valgte objekt kommer forrest. Drejningen af træet sker via flydende animation, så brugeren ikke mister orienteringen. Det er også muligt at foretage en regulær søgning udfra brugerindtastede kriterier. Brugeren kan vælge at skjule enkelte dele (grene) af træet; søgningen foregår da i den synlige del af træet. Ønsker brugeren at flytte objekter, eller samlinger af objekter, fra en del af træet til en anden kan dette ske vha. drag&drop teknikker som kendt fra Windows.


Figur 2: The Perspective Wall

5.1.2 The Perspective Wall
The Perspective Wall [Mackinlay m.fl. ´91] er beregnet til at vise lineært strukturerede informationer, som kan være svære at overskue på en almindelig, flad skærm. Informationerne vises på en væg, hvor væggens ender er bukket. På den midterste del af væggen ses de informationer, man primært er interesseret i, mens konteksten fremgår af de bukkede ender. På den måde kan man bevare overblikket over informationerne, selv når man betragter dem på et detaljeret niveau.

Figuren viser et filoversigtssystem, hvor x-aksen repræsenterer datoen og y-aksen repræsenterer filtypen. Væggen kan scrolles, hvilket sker vha. flydende animation. Det er således muligt at vælge et objekt på en af de bukkede ender og få det scrollet ind i fokus. Det gør, at samtlige objekter meget hurtigt kan findes frem. Det er også muligt at foretage en søgning efter f.eks. lignende og relaterede objekter 'similar related' objekter, en teknik der drager fordel af væggens mulighed for at vise objekter fordelt over hele informationsområdet på én gang.

5.1.3 Time Lattice
Time Lattice [Mackinlay m.fl. ´94] har til formål at visualisere en kalender for en gruppe af personer. Aftalerne i kalenderen er vist som en sky af kasser i midten af et 2½D rum arrangeret efter de tre dimensioner time, dag og person. Hver person har sin egen farvekode, hvilket gør det lettere at overskue skyen.


Figur 3: Time Lattice

På tre af væggene i rummet kan skyens skygger ses. Dette gør det muligt at se en opsummering af antallet af aftaler for et givet sæt af to koordinater. Brugeren har mulighed for at vælge det viste tidsrum og enkelte personer kan slås til og fra vha. knapper ud for personernes navne. Det er muligt at foretage forskellige søgninger, bl.a. kan brugeren få vist aftaler, der repeteres; i dette tilfælde vises aftaler, der ikke repeteres, som gennemsigtige kasser.

5.1.4 The Cognitive Coprocessor
Den kognitive coprocessor [Robertson m.fl. ´89] er en form for brugergrænsefladearkitektur, og indgår som en del af Information Visualizer. Den kommer med en løsning på et problem affødt af tids- og ressourcemæssige begrænsninger. Problemet udgøres af den koordinationsopgave der opstår, når man kombinerer et interaktivt system, hvor der dels pågår en menneske-maskin dialog, og dels pågår en række underliggende arbejdsprocesser i maskinen. Dette samtidig med at brugergrænsefladen benytter sig af 3D grafik og animationer. De to problemer betegnes som "The Multiple Agent Problem" og "The Animation Problem".

Agenterne udgøres af mennesket (User), den del af maskinen som fører dialogen med mennesket (User discource Machine), og den del af maskinen som udfører opgaverne (Task Machine). Flaskehalsen for samspillet mellem disse agenter udgøres af de begrænsede computerressourcer. Problemet forværres yderligere, hvis Task Machine er underopdelt i såkaldte agenter, der fungerer asynkront i forhold til hinanden, samt hvis det datagrundlag de opererer på ikke er kendt på forhånd. For yderligere at komplicere problemet, så er en af parterne (brugeren) ikke en maskine. At få animationer til at se virkelighedstro ud er egentlig ikke noget problem, hvilket har været bevist i tegnefilm siden 30'erne. Problemet opstår, når man prøver at løse de to førnævnte problemer samtidig. Eftersom der er tale om et interaktivt system, kan kravet til animation ikke forudses på forhånd. Men animationer må under ingen omstændigheder hakke.


Figur 4: The Cognitive Coprocessor

Opgavekø er en liste over arbejdsopgaver som skal udføres. Visningskø er en liste over animationer der skal vises. En Govenor er et slags timermodul, der holder styr på tiden, så loopet kan gennemløbes 30 gange i sekundet, og justerer animationerne derefter. Det centrale element er animationsløkken, der holder styr på alle elementerne. Det fungerer således: Først opdateres govenor. Så processeres input fra brugeren, og derefter processeres arbejdsopgaver. Så tegnes visning, og til sidst køres løkken igen.

Govenors justeringer af animationerne foregår på den måde, at hvis de forhåndenværende ressourcer ikke muliggører at de ønskede animationer afvikles optimalt, så kan baggrunden og mindre væsentlige detaljer nedsættes i opløsning og opdateringshastighed, medens animationerne af objekt(erne) i fokus stadig afvikles optimalt. Hvis der er tale om at der er blevet sat meget tidskrævende arbejdsprocesser i gang, som f.eks. en databasesøgning, så kan informationer vises for brugerne efterhånden som de bliver fundet. På denne måde kommer brugeren ikke til at tro at systemet er gået ned. Samtidig kan brugeren benytte objekterne med det samme efterhånden som de vises, og måske sætte en ny søgning i gang, endnu før den forrige er afsluttet.

5.2 File System Navigator
File System Navigator (FSN) kendes af de fleste fra filmen Jurassic Parc. I filmen anvendes FSN af hovedpersonerne til at overvåge et stort fil-netværk. FSN er lavet af Silicon Graphics. FSN er kun udviklet i en desktop VR version og understøtter således ikke anvendelse af f.eks. 3D input-devices.


Figur 5: File Systems Navigator (FSN)

FSN er beregnet til visualisering af store filnetværk (dvs. hierarkisk information). De enkelte filer visualiseres som datablokke, hvis højde, farve etc. bestemmes af filens størrelse, alder, attributter m.v. Filer beliggende i samme biblioteker samles i celler, der indbyrdes er forbundet. Cellerne er placeret i et landskab, hvor den enkelte celles position afhænger af dens placering i fil-hierarkiet. Brugeren har kun få muligheder for at ændre visualiseringen.

Brugeren kan bevæge sit view-point gennem landskabet og på den måde gennemsøge data. Denne bevægelse kan enten foregå som fri flyvning eller ved at brugeren klikker på en datablok, celle eller connector og automatisk bliver ført derhen. Enkelte datablokke kan udvælges, hvorved de bliver markeret med en spotlight. Filer kan editeres, flyttes, kopieres, slettes, printes og endog eksekveres.

5.3 Sphere-Based Visualization
Institute of Systems Science's Sphere-Based Visualization. Denne teknik [Vexelblat] er implementeret i praksis i KICK, et multimedia forfatterværktøj. Som testdata er de interne strukturer i KICK benyttet; disse strukturer udgøres af multimedia information objekter organiseret via hierarkier og indbyrdes associationer.


Figur 6: Institute of Systems Science´s sphere

Teknikken visualiserer vha. 2½D grafik moderate mængder af indbyrdes relaterede objekter. Visualiseringen har form som en kugle, hvor de enkelte objekter er placeret efter deres relation til et udvalgt objekt, således at et objekt tæt knyttet til det udvalgte objekt er placeret tæt på dette. Kuglen består af flere lag, og objekter, der er indirekte relaterede til det udvalgte objekt, befinder sig i disse lag. Kuglen kan roteres og forskydes, og brugeren kan bevæge sig ud og ind gennem de enkelte lag. De enkelte objekter er visualiseret vha. en version af AutoIcon (se nedenfor).

5.4 Visualization Prototype
Fairchilds visualization prototype prototype [Vexelblat] er ikke implementeret i praksis. Den er en illustration af Fairchilds principper for visualisering af informationer og forbindelser mellem disse. I prototypen visualiseres det enkelte objekt vha. en metode kaldet AutoIcon. AutoIcon fastlægger ikonens udseende (farve, form, bitmap etc.) udfra objektets attributværdier, og under brugen af systemet kan brugeren ændre denne mapning. Ikonerne svæver i et rum og vises i forskellig detaljeringsgrad afhængigt af afstand til brugerens view-point og relevans for brugeren (Degree Of Interest). Ydermere forvrænges objekternes position i 2½D rummet, således at relevante objekter rykker tættere på view-point og delvist følger brugeren, når denne bevæger sit view-point. Systemet kan visualisere multivariate data af en hvilken som helst type og er bedst egnet til moderate datamængder, idet det ved store datamængder vil blive uoverskueligt. Søgning og navigering foregår vha. sekvenser af gestus (Gesture Sequence Navigation). Disse gestus kan være tastetryk, musebevægelser, håndbevægelser med DataGlove eller lign. Langs kanten af synsfeltet får brugeren feedback på sine valg og kan se, hvilke valg, der nu er mulige.

5.5 SemNet
SemNet [Vexelblat] blev udviklet af Microelectronics and Computer Technology Corporation med det formål at undersøge, hvordan store vidensdatabaser kan præsenteres så de er forståelige for brugeren. Vidensdatabaser er karakteriserede ved, at de enkelte objekter er indbyrdes relaterede.

SemNet visualiserer vidensdatabasens objekter som rektangler svævende i et 2½D rum. De enkelte objekter er kun karakteriseret ved deres navn og position i rummet samt deres relationer til andre objekter. Positionen bestemmes udfra objektets relationer, således at det befinder sig tæt ved de objekter, det er relateret til. Objekterne er inddelt i klynger, og én sådan klynge vises som et enkelt objekt, når det er tilpas langt fra brugerens view-point. Brugeren kan således kun se de objekter, der er tæt på, som individuelle objekter. Søgning i SemNet foregår bl.a. ved at bevæge view-point rundt mellem objekterne.

5.6 3D Inforoom
3D Inforoom [Benedikt] eksisterer kun som et teoretisk eksempel på, hvordan en VR brugergrænseflade til håndtering af store informationsmængder kunne implementeres. Systemet er designet med henblik på håndtering af en billeddatabase indeholdende en stor mængde objekter (ca. 300.000 billeder). I Benedikts beskrivelse af 3D Inforoom er det ikke endeligt afgjort, om systemet skulle implementeres som 2½D eller som 3D; i det følgende vil vi antage, at det implementeres i 3D.

I 3D Inforoom visualiseres informationerne i et 3D rum. Brugeren vælger tre dimensioner (objektattributter), og disse dimensioner vises parvis på væggene. Informationsmængden (eksempelvis angivet i antal Mb) vises på væggene vha. enten farver, relief, eller rektangler af forskellig størrelse. Ifbm. denne visning kan brugeren vælge, om informationsmængden skal vises uafhængigt af den valgte værdi for den 3. dimension (der ikke vises på den pågældende væg) eller afhængigt af den valgte værdi for den tredje dimension.


Figur 7: Benedikts 3D inforoom

Brugeren befinder sig i det 3-dimensionelle rum på et fartøj, og dette fartøj kan frit bevæges rundt i rummet, endda et stykke uden for rummet for at give et bedre overblik over rummet (den forreste væg er i så tilfælde usynlig). Derudover styrer brugeren en probe (3D markør), der via linier peger på de valgte koordinater på væggene. Han kan vælge at udfolde de informationer, som befinder sig på de valgte koordinater. Dette åbner et underrum, som brugeren selv kan placere i det store rum. I dette underrum er de udvalgte informationer vist i tre andre, af brugeren valgte dimensioner, og på en af væggene kan selve objekterne (billederne) betragtes. Underrummet har sin egen probe, der kan bevæges uafhængigt af den oprindelige probe.

5.7 Oversigt over isualiseringsteknikker
Det følgende skema skulle gerne give et overblik over de otte visualiseringsteknikker, der er blevet gennemgået i de foregående afsnit. For hver visualiseringsteknik er der kort beskrevet, hvilke data teknikken er beregnet på, hvordan den visualiserer dem, og hvilke interaktionsmuligheder brugeren har.

Cone Trees Perspective Wall Time Lattice File Systems Navigator Sphere Visualization Prototype SemNet 3D Inforoom
Struktur
Hierarkisk
Liniær
3D (time, dag og person)
Hierarkisk (filnetværk)
Hierarkisk, indbyrdes associeret
Multivariate data
Vidensbase
Billeddatabase
Mængde
Mellemstor (op til 10000)
Mellemstor
Lille (ca. 10 personer)
Stor
Mellemstor
Mellemstor
Stor
Stor (ca. 300000)
Antal Dimensioner
2½D
2½D
2½D
2½D
2½D
2½D
2½D
2½D eller 3D
Visualisering af objekter
Rektangler med tekst
?
Farvede kasser og kvadrater
Blokke med højde, farve etc. bestemt af filattributter
AutoIcon (se tekst)
AutoIcon (se tekst)
Rektangler med tekst
Farver, relief eller rektangler
Visualisering af sammenhænge mellem objekter
Træstruktur
Langstrakt 2D væg med bukkede ender
Tre vægge med hver to dimensioner. Sky med tre dimensioner
Celler (samlinger af blokke). Forbindelser mellem celler
Position på kugleoverflade. Position i kuglelag.
Position i rummet. Forbindelser mellem objekter.
Position i rummet. Indbyrdes forbindelser. Klynger af objekter.
Position i 2D koordinatsystemer på vægge i rum.
Input device(s)
Mus og tastatur
Mus og tastatur
Mus og tastatur
?
?
Mange mulige: mus, handske, tastatur mfl.
?
?
Navigering
Friflyvning. POI logaritmisk flyvning.
Friflyvning. POI logaritmisk flyvning.
Friflyvning. POI logaritmisk flyvning.
Friflyvning. POI flyvning.
Bevægelse mellem lag. Drejning af kugle
Friflyvning
Friflyvning
Friflyvning
Søgning
Drejning af træ. Almindelig søgning
Scrolling. Almindelig søgning
Almindelig søgning
Almindelig søgning
?
Almindelig søgning
?
Udvælgelse med probe. Valg af underrum
Manipulering af objekter
Drag and drop
?
?
Flytning, kopiering etc.
?
?
?
?
Manipulering af visualisering
Skjulning af dele af træ
?
Fravalg af enkelte personer
?
?
AutoIcon (se tekst)
?
Valg af visualiserings- tilstand. Valg af dimensioner

Bemærk, at når der under søgning står "almindelig søgning", så betyder det, at søgningen foregår på traditionel vis med en form for forespørgsel, og ikke ved manipulering af grafiske objekter o.lign


6. Design

Da udformningen af designet i høj grad afhænger af de data, som systemet skal håndtere, har vi valgt at indlede designovervejelserne med en gennemgang af biblioteksdatabasens vigtigste karakteristika og databasens underliggende struktur. Herefter diskuteres kort forskellige visualiseringsteknikkers anvendelighed til at repræsentere biblioteksdatabasens indhold. Med udgangspunkt i denne diskussion gennemgås herefter designet af vores bud på en 'Det virtuelle Bibliotek'-database.

6.1 Biblioteksdatabasen
Som datagrundlag for vores visualiseringsprototype har vi valgt en eksisterende biblioteksdatabase på en højere læreanstalt. Vi kunne også have valgt en virksomheds regnskabsdatabase, en elektronisk lovsamling eller noget helt fjerde. Når vi har valgt biblioteksdatabasen, er det fordi søgning i biblioteksdatabaser netop drejer sig om at overskue store informationsmængder.

Det er derfor tankevækkende, at de brugergrænseflader, der vanligvis findes til søgning i biblioteksdatabaser oftest udmærker sig ved deres manglende brugervenlighed. Mange eksisterende bibliotekssystemer er type A brugergrænseflader (se afsnit 4.1), der fordrer at brugeren tillærer sig en bestemt søgesyntaks, førend systemet kan anvendes. Endvidere lider næsten alle eksisterende bibliotekssystemer af den svaghed, at de udelukkende er velegnede til specifikke søgninger. Søger man efter en bestemt bog, hvor forfatterens navn eller et ord i titlen kendes, da er disse systemer fortrinlige. Men ønsker man at gå på opdagelse i databasen, eller danne sig et overblik over, hvad der er publiceret indenfor et bestemt fagområde, er disse systemer meget lidt anvendelige. Når en bruger søger i en biblioteksdatabase, foregår det som regel vha. et eller flere nøgleord. Brugeren søger på f.eks. 'operativsystemer' og får så præsenteret en liste på 1200 titler, alle omhandlende (mere eller mindre perifert) dette emne. Det, brugeren nu har behov for, er at kunne overskue denne datamængde og f.eks. se, hvorledes de enkelte titler hænger sammen med andre emneområder. Det kan også være, at brugeren er interesseret i at se, i hvilke år der er skrevet mest om emnet, eller hvor i verden. Sammenhænge, som stort set er umulige at udlede fra en almindelig liste.

Biblioteksdatabasen indeholder ca. 400.000 emner (bøger, artikler, tidsskrifter mv.) repræsenteret i HERMES-format, hvilket (bl.a.) omfatter følgende oplysninger:

Udover disse oplysninger er der oplysninger til intern brug (bestilling etc.) samt oplysninger om mere specielle objekter, såsom antologier, serier og konferenceudgivelser.

Databasen er karakteriseret ved at have et meget stort antal objekter, som brugeren har behov for at overskue. Samtidig skal brugeren på et meget detaljeret niveau kunne skelne mellem og udvælge enkelte titler, hvilket betyder, at der er behov for to niveauer af visualisering: et til overblik og et til detaljer. Disse behøver ikke nødvendigvis at være skarpt adskilte; der kan godt være en flydende overgang. Der er ingen relationer mellem objekterne, idet ingen af dem refererer til hinanden (der er f.eks. ikke noget forfatterobjekt, som tyve bøger af samme forfatter refererer til), så vores system vil ikke få behov for at vise direkte sammenhænge mellem objekterne. Derimod vil det være interessant at kunne visualisere mønstre i informationsmængden.

Den funktionalitet, som kræves af vores system, afhænger naturligvis af brugeren. Til et bibliotekssystem kan der tænkes to typer af brugere: Låneren og bibliotekaren. Låneren har behov for at kunne søge i databasen og finde relevante informationer, mens bibliotekaren udover dette også har behov for at kunne oprette, flytte, ændre og slette objekter. Typen af brugere påvirker også kommunikationen mellem bruger og system, idet en professionel bruger som bibliotekaren vil være mere interesseret i effektiv og hurtig kommunikation, i modsætning til låneren, der oftest vil være interesseret i enkel kommunikation og færre avancerede faciliteter. I det følgende antager vi, at systemet skal kunne betjenes af både lånere og bibliotekarer, hvilket giver os lejlighed til at designe alle tre aspekter af systemet (visualisering, søgning og manipulering).

6.2 Diskussion af teknikkers egnethed
Som det fremgik af præsentationen af de enkelte visualiseringsteknikker, har hver teknik sit anvendelsesområde. I det følgende vil vi vurdere, hvorvidt de enkelte teknikker er egnede til løsning af den aktuelle problemstilling.

3D Inforoom: Vores data minder meget om dem, der ligger til grund for Benedikts visualiseringsteknik, og mængden af informationer er af samme størrelsesorden. På et punkt adskiller de to problemer sig dog fra hinanden: objekterne i 3D Inforoom er billeder, og har derfor en naturlig visualisering (billedet selv) i modsætning til vores tekstobjekter. Dette har dog ingen betydning for overbliksniveauet, hvor de individuelle objekter er visualiseret som punkter. Som overbliksteknik mener vi, at selve rumideen er glimrende, og den vil vi anvende i vores eget system.

Time Lattice: Time Lattice minder en hel del om 3D Inforoom, idet denne teknik ligeledes har tre dimensioner illustreret parvis på væggene. Det, der gør den speciel, er den sky af objekter, som hænger i midten af rummet, og som hjælper med til at give et overblik over informationen. En tilsvarende feature vil vi anvende i vores system, både for at give brugeren et overblik over data og for, på det detaljerede niveau, at give brugeren mulighed for at se objekternes faktiske placering i rummet.

Visualization Prototype: Visualiseringen af sammenhængen mellem objekterne i denne teknik er ikke velegnet til vore system, idet vores informationsmængde er for stor og objekterne indbyrdes urelaterede. Derimod kan visualiseringen af det individuelle objekt (mapping fra attributter til ikon) med fordel anvendes til det detaljerede niveau, fordi den kan bruges til at anskueliggøre ellers abstrakte attributter. Dette gøres ved at omsætte objektets felter som type, omfang etc. til ikonegenskaber som form, farve etc.

The Perspective Wall: Idet The Perspective Wall kun kan visualisere informationer i to dimensioner, er teknikken ikke velegnet til at give overblik i vores system. På det detaljerede niveau kunne den imidlertid anvendes til at visualisere et lille antal objekter ud fra to brugervalgte dimensioner. Dette ville dog kræve, at brugeren skiftede mellem to visualiseringsteknikker (med mindre man kunne indbygge en Perspective Wall i overbliksvisualiseringen), en fremgangsmåde som vi dog ikke finder hensigtsmæssig.

File Systems Navigator: Vi kunne godt i vores system vise objekterne spredt ud på en 'slette' som i FSN, hvilket svarer til at vise dem på gulvet i et 3D Inforoom, blot i et andet størrelsesforhold. Da vores biblioteksdata imidlertid ikke er hierarkisk strukturerede, ville vi ikke opnå de samme fordele som i FSN.

SemNet: SemNet kan ikke anvendes, da biblioteksdatabasen ikke er struktureret som en vidensbase med indbyrdes relaterede objekter.

Cone Trees: Denne teknik kan ikke anvendes, idet biblioteksdatabasen ikke er hierarkisk struktureret.

Sphere: Denne teknik kan ikke anvendes, da objekterne i biblioteksdatabasen ikke er struktureret i et hierarki og ikke er indbyrdes relaterede.

6.3 Design af Det virtuelle Bibliotek database
Designovervejelserne er overvejende inspireret af Benedikts 3D inforum. Dette gør sig særligt gældende for søgning- og visualiseringsdelen, der dog også rummer ideer fra The Information Visualizer og Fairchild. Navigationsteknikkerne er primært inspireret af The Information Visualizer, mens manipulationsdelen er eget arbejde.

6.3.1 Rummets udseende
Når man træder ind i systemet, kommer man ind i et kubisk rum. Det første, man bemærker, er, at samtlige vægge, incl. gulv og loft, er dækket af punkter.


Figur 8: Det første udkast til design

Hver væg udgør et koordinatsystem; øverst på væggen står en tekst, f.eks. årstal, og ned langs kanten af væggen står en anden tekst, f.eks. forfatter. På en anden væg står forfatter og emne, og på en tredje væg emne og årstal. Selve rummet er tomt. De tre nævnte vægge er tilstrækkelige til at gengive tre dimensioner, men vi har valgt også at benytte de resterende tre vægge. Dette giver mulighed for at vise de samme informationer i to modes på samme tid, hvilket vi kommer nærmere ind på senere.

Hvert punkt repræsenterer et objekt i databasen, i dette tilfælde en bog (eller artikel etc.), og punktet er placeret i hver vægs koordinatsystem, således at dets placering modsvarer prikkens værdier for væggens to dimensioner. Dette gør, at man kan overskue store mængder af bøger og opdage mønstre i informationerne, f.eks. hvor og hvornår, der blev skrevet mest om kunstig intelligens. Dette er den grundlæggende vægkonfiguration, kaldet pointmode, som systemet starter op med. Udover den nævnte tilstand, hvor væggenes indhold vises som punkter, er der to andre tilstande: colormode og objectmode. Disse tilstande kan vælges for de individuelle vægge uafhængigt af, hvad der er valgt for de øvrige vægge.

I colormode vises væggens indhold som en matrix af farvede firkanter. Hver firkant har en farve, som symboliserer mængden af objekter for det pågældende koordinatsæt (en farveskala fra blå til rød, hvor blå = lavt antal objekter og rød = højt antal). Denne tilstands fordel frem for pointmode er, at punkterne i pointmode kan være sammenfaldende, hvilket gør det svært at gennemskue tætheden; i det tilfælde vil colormode give et bedre overblik.

I objectmode vises det enkelte objekt som en ikon, hvis udseende afhænger af objektets attributter. Denne tilstand er bedst egnet ved små mængder objekter, dvs. når brugeren har afgrænset sig til et lille område.

Hvis brugeren ønsker det, kan der aktiveres en feature kaldet sværm. Aktiveres den, fremkommer en sværm af punkter i rummet. Denne sværm viser objekterne som punkter hængende i rummet, hvilket giver brugeren mulighed for at bevæge sig rundt blandt dem og danne sig et indtryk af deres tæthed.

Udover den nævnte pointmode har sværmen to andre tilstande, svarende til væggenes tilstande: Colormode og objectmode. Alle tre tilstande kan vælges uafhængigt af væggenes tilstand. Colormode angiver ved eksempelvis 10*10*10 farvede kugler (samme farveskala som væggenes colormode), hvordan objekterne er fordelt, mens objectmode viser objekterne som tredimensionale udgaver af væggenes ikoner. Objectmode kan dog kun anbefales, hvis antallet af objekter i rummet er lille; i modsat fald vil rummet blive så fuldt af objekter, at man mister overblikket.

For både sværm og væg kan der vælges et net (engelsk: grid). Er denne slået til, bevæger proben sig trinvist i stedet for flydende. Hvis brugeren ønsker det, kan sværmen komprimeres, så den kun fylder et udsnit af rummet.

En sidste mulighed for at påvirke rummets udseende er, at man kan vælge compressed walls. Når dette er valgt, udfyldes eksempelvis kun den midterste 1/9 af hver væg med informationer, hvilket gør væggen lettere at overskue. Ydermere svarer denne vægstørrelse til den lille udgave af sværmen, således at skalaen for væg og sværm er den samme.

6.3.2 Objekters udseende
Når brugeren har valgt objectmode for enten sværmen eller en af væggene, skal objekterne vises detaljeret. Til at visualisere objekterne vil vi anvende en teknik inspireret af Fairchilds AutoIcon. I AutoIcon omsættes objektets attributter til en ikon med størrelse, form, farve, bitmap etc. I vores system vil vi på samme måde udvælge de efter vores mening vigtigste attributter og mappe dem til en objektikon. Denne objektikon skal dog ikke blot være en flad ikon som i AutoIcon, men derimod en gengivelse af det fysiske objekt, som databaseobjektet refererer til. Er det fysiske objekt således en bog, skal databaseobjektet repræsenteres som en bog i vores system, en cd-rom skal repræsenteres som en cd-rom, en artikel som en artikel etc. Objektikonen skal have følgende karakteristika:

Til disse karakteristika vil vi knytte disse attributter:

form = ojekttype (bog, artikel etc.)
farve = alder (år)
forside bitmap = udlånt/ikke udlånt/reserveret etc.
forside tekst = titel + forfatter
tykkelse = omfang (antal sider)

Selv om objekterne vises på en todimensionel væg, skal de stadig have tykkelse. Dette opnås ved, at de buler ud fra væggen. For at bevare overensstemmelsen med virkelighedens objekter kan en objektikon nødvendigvis kun have én forside. Dette kan være en ulempe, når objekterne svæver i rummet, fordi man så er nødt til at stå på den rigtige side af dem for at kunne se alle detaljerne. Hvis objektets titel- og forfatterfelter er lange, kunne ikonens tekst blive meget lille og svær at læse på afstand. I så tilfælde skal systemet vælge blot at vise en del af teksten (f.eks. max. 30 karakterer), og så lade brugeren vælge objektet, hvis hele teksten ønskes vist.

6.3.3 Navigation
Som tidligere nævnt opfatter vi navigation som bevægelse af brugerens point-of-view i inforummet. Hvad brugeren ser i sit point-of-view afhænger af dets position og orientering. I Det virtuelle Bibliotek har vi valgt at lade orientering for brugerens point-of-view bestemme af hovedbevægelserne, mens ændring af position for point-of-view sker ved bevægelse af en 3D mus. Herved bibeholdes VR brugergrænsefladens måske største fordel, nemlig at den tillader brugeren på en meget intuitiv forståelig måde at orientere sig i den virtuelle verden (vha. hovedbevægelser), samtidig med at bevægelse, særligt over store afstande, kan foregå hurtigt og ubesværet. Inspireret af navigationsteknikkerne anvendt i The Information Visualizer [Mackinlay m.fl., 90], kan ændring af position i inforummet ske enten ved Walking Metaphor eller point-of-interest-logarithmic-flight.

Walking Metaphor tillader brugeren at flyve i en vilkårlig retning med vilkårlig hastighed i de virtuelle omgivelser. Retningen og hastighed for bevægelse i inforummet bestemmes af brugerens håndbevægelser med 3D musen og den hastighed hvormed de foretages. I The Information Visualiser anvender man også Walking Metaphor navigation, om end i en mere restriktiv form. Vha. et sæt af virtual joystick controls kan man bevæge sig enten op/ned, frem/tilbage og højre/venstre. Selv om denne metode principielt tillader brugeren at bevæge sig frit i det virtuelle miljø, er metoden omstændelig og beværlig, for det første fordi man kun kan justere en positionsvariabel ad gangen. For det andet fordi man kun kan bevæge sig med konstant hastighed. Ved at anvende et 3D inputdevice, som f.eks. en 3D mus overvindes disse besværligheder. Her er man ikke begræset til enten at bevæge sig op/ned frem/tilbage eller højre/venstre men kan f.eks. bevæge sig skråt opad, bevæge sig mod venstre samtidig med at man daler en smule eller foretage komplicerede kurvede bevægelser osv. Endvidere kan hastigheden på bevægelsen let justeres ved at bevæge hånden langsommere eller hurtigere efter behov.

Point-of-interest-logarithmic-flight navigationsteknikken er hentet fra The Information Visualizer. Forfatterne bag The Information Visualizer fandt at Walking Metaphor navigation med fordel kunne suppleres med en navigationsform, der tillader hurtig og præcis bevægelse rettet mod bestemte punkter eller objekter som brugeren er interesseret i. Hænger der eksempelvis et objekt forholdsvis langt borte fra brugeren kan det tage tid at navigere sig hen til objektet vha. traditionelle navigationsteknikker som f.eks. Walking Metaphor. Brugeren bør kunne markere et point-of-interest og derefter hurtigt og præcist blive bragt til dette punkt. Et vigtigt spørgsmål i denne sammenhæng er hvilken hastighed bevægelsen skal foretages med. Man kan minimum forestille sig følgende alternativer:

Bevægelse med konstant hastighed er ikke anvendelig da bevægelse mod meget fjerne punkter, i hvertfald teoretisk set, kan tage uendelig lang tid. Uendelig hurtig bevægelse er heller ikke anvendelig da brugeren ved den slags hop, eller "klip i filmen", skal bruge uforholdmæssig meget tid på at genvinde orienteringen umiddelbart efter hoppet. Der skal være en transporttid for at brugeren kan beholde orienteringen undervejs. En mulig løsning er at lade hastigheden være ligefrem propotional med den afstand, der skal tilbagelægges. Transporttiden bliver da den samme, uanset om det valgte point-of-interest er langt borte eller tæt på og brugeren mister ikke orienteringen undervejs. Sidstnævnte metode kan raffineres yderligere ved at lade hastigheden aftage logaritmisk. Dvs at bevægelsen i starten sker med høj hastighed. Jo længere væk objektet er, desto højere starthastighed. Men efterhånden som brugeren nærmer sig objektet aftager hastigheden logaritmisk. Fordelen ved denne teknik, som har givet navn til navigationsformen "Point-of-interest-Logarithmic-flight", er at brugeren ved ankomsten til den nye position får tid til at orientere sig i de nye omgivelser. Bemærk i øvrigt at i Information Visualiser udgaven styres også brugerens orientering mod det valgte point-of-interest. Dette er en nyttig detalje i et desktop VR miljø, men aldeles uanvendeligt i VR, fordi brugerens orientering altid bør styres af hovedbevægelser. Vi har derfor valgt at undlade denne lille detalje i inforummet.

Generelt er navigationen underlagt den restriktion at point-of-view ikke kan overskride inforummets grænser. Brugeren kan altså ikke gå igennem rummets mure. Man kunne indvende, at det for overblikkets skyld kunne være hensigtsmæssigt at kunne betragte rummet udefra gennem transparente vægge. Dette problem har vi imidlertid valgt at løse ved at tillade brugeren at visualisere inforummet i compressedmode (beskrevet ovenfor), hvor data kun får lov til at udfylde en delmængde af det totale rum. Et koncept der bl.a. anvendes i Time-lattice visualiseringsteknikken i The Information Visualizer.

6.3.4 Manipulation
Vi skelner helt overordnet mellem to former for manipulation, nemlig manipulation af visualisering og manipulation af data. Manipulation af visualiseringen vedrører valg af variable for inforummets tre dimensioner, fastsættelse af afgrænsninger, valg af visualiseringstilstande for både vægge og sværm, mens manipulation af data vedrører oprettelse, flytning, ændring og sletning af objekter.

Manipulation af både visualisering og data involverer et væsentligt element af kommunikation af symbolsk karakter. Eksempelvis skal brugeren initielt tage stilling til hvilke dimensioner rummets vægge skal visualisere, samt fastsætte start og slut værdi for hver dimension, evt. fastsætte en dimension til et bestemt søgeord osv. I The Information Visualizer foregår denne kommunikation via et almindeligt tastatur. Den mulighed er i sagens natur ikke til rådighed i en ægte VR brugergrænseflade. Her må der udtænkes andre teknikker til kommunikation af information af symbolsk karakter. En mulighed kunne være at kommunikere via et virtuelt tastatur. Dvs. et tastatur, der på brugerens kommando kan fremkaldes i den virtuelle verden. Skrivning af ord foregår ved f.eks. at klikke med en cursor på de relevante bogstaver.

Selv om denne løsning principielt er anvendelig er den omstændelig og besværlig at anvende. Den er et skoleeksempel på overførsel af et forældet medies teknikker til et nyt medie. Den naturlige kommunikationsmetode af symbolinformation i VR må være gennem talegenkendelse. Teknologien er endnu ikke færdigudviklet, men alt tyder på at den vil være tilgængelig, også for menigmand inden for ganske få år. Vi forudsætter derfor at talegenkendelse indgår som en væsentlig bestanddel i manipuleringen af både visualiseringen og data.

Manipulation af visualisering
Mere specifikt forestiller vi os at manipulation af visualiseringen sker gennem en kombineret anvendelse af talegenkendelse, en 3D cursor og en såkaldt "menuvæg", hvor sidstnævnte er en transparent menu, der kan kaldes frem på brugerens kommando. En 3D cursor svarer til en 2D cursor, som de kendes fra WIMP-brugerinterfacet (WIMP= Windows Icon Menu Pointing). Dog med den vigtige forskel at cursoren kan bevæges ind i skærmen. 3D cursoren anvendes som en almindelig cursor til at pege på, hive i og droppe objekter. Menuvæggen indholder faciliteter til at fastsætte variable og afgrænsninger for rummets 3 dimensioner og visualiseringstilstande for både vægge og sværm. I nedenstående skema er vist valgmulighederne i menuvæggen:

Variable Afgrænsninger Wall Swarm
1. dimension
1. dimension
Skift mellem pointmode, colormode og objectmode
Swarm til/fra
2. dimension
2. dimension
Grid til/fra
Skift mellem pointmode, colormode og objectmode
3. dimension
3. dimension
Komprimering til/fra
Grid til/fra
Komprimering til/fra

Valg af et vilkårligt menupunkt foregår ved enten at udtale den ønskede kommando, eller ved at markere menupunktet med 3d-cursoren. I mange tilfælde vil menuen dog helt kunne overspringes. F.eks. vil valg af variabel og tilhørende afgrænsninger for en af de tre dimensioner kunne fastsættes ved at klikke med 3D-cursoren på en af akserne/kanterne i rummet. Opsætning af visualiseringsvalg for en vilkårlig væg kan ske ved at klikke på denne væg, hvorved et opsætningsvinduet for den pågældende væg fremkommer.

Manipulation af data
Eftersom vi antog, at systemet også henvender sig til bibliotekarer, skal der være mulighed for at ændre objekters attributter (herunder oprette nye objekter og slette gamle). Dette skal kunne foregå på to måder: direkte editering og drag&drop.

Ved direkte editering får brugeren ved at vælge et objekt en fuldstændig tekstgengivelse af objektet op foran sig, således at rummet stadig kan ses bagved. Brugeren kan nu rette i de enkelte felter, hvilket gøres ved at han peger på det pågældende felt og vha. tale meddeler systemet de ønskede rettelser. Via talte kommandoer kan han vælge at oprette og slette objekter.

Ved drag&drop griber brugeren fat i et objekt. Han kan nu via en kommando få en kopi af objektet, eller han kan manipulere det faktiske objekt. Flytter han objektet til en ny lokation, ændrer han de pågældende attributter, og krøller han det sammen og smider det væk, sletter han det. Ønsker han at gemme objektet, f.eks. fordi han er ved at udarbejde en liste, kan han lægge det i en virtuel kurv, som befinder sig nederst i synsfeltet og følger ham, hvor han bevæger sig hen.

6.3.5 Søgning
Søgning i vores system foregår ved, at brugeren gradvist indsnævrer informationsområdet, indtil objekternes tæthed er så lav, at enkelte objekter kan udvælges. om at få dette område forstørret op, så det fylder Indsnævringen udføres ved at vælge et område i tre dimensioner og bede systemet hele rummet, dvs. afgrænsningen på de tre dimensioner indsnævres. Denne proces kan gentages, så mange gange det er nødvendigt, hele tiden med mulighed for at gå et eller flere skridt tilbage vha. en fortryd-funktion.

Proben er den cursor, der markerer, hvilke objekter brugeren har valgt. Proben befinder sig i det tredimensionale rum og kaster et spotlight ud på hver væg. Dette spotlight er firkantet og oplyser det område af væggen, som brugeren har valgt. Proben i rummet har form som en kasse, hvor de enkelte sider i størrelse svarer til de udvalgte områder på væggene. For ikke at blokere synsfeltet for brugeren er proben semi-transparent.

Proben kan påvirkes både i 3D og 2D formen, hvilket gøres ved at hive i kanterne af den, hvis man ønsker at ændre størrelsen, og ved at placere cursoren inde i proben og trække i den, hvis man ønske at ændre probens position. 3D og 2D formen følges altid ad, så ændrer man den ene, ændes den anden samtidigt. Hvis brugeren ønsker det, kan proben følge den valgte grid, således at størrelsen af proben kun kan ændres trinvist.

Et tænkt eksempel på en søgning kunne være: Vi ønsker at undersøge indenfor hvilke forskningsområder, der er skrevet om intelligensbegrebet. Specielt er vi interesseret i populærvidenskabelige artikler, evt. mindre bøger om emnet. Endelig er det afgørende at materialet er af nyere dato. Søgning startes ved først i menuvæggen at angive variable for de tre dimensioner. Som første dimension vælger vi variablen Titel, som anden dimension emneområde og som tredje dimension årstal for udgivelse. Som afgrænsning vælger vi Titel = "Intelligens", emneområde = all og årstal = all. Interessant er nu den væg som kombinerer emneområde og årstal. Denne væg er belagt med adskilte aflange streger af punkter. Indenfor langt de fleste emneområder er der meget lidt eller slet intet om intelligensbegrebet. Men nogle få er tæt belagt med punkter. I bunden af væggen ses at det primært drejer sig om følgende emneområder: Biologi, psykologi, filosofi, datalogi og medicin. Vi beslutter at kigge nærmere på psykologi i perioden 1990 - 1995. Denne klump udvælges med proben og det valgte udsnit skaleres op, så det fylder hele rummet. Vi vælger nu at dimensionere den udvalgte mængde efter følgende variable: forfatternavn, årstal og sprog. Da den udvalgte mængde nu er reduceret betragteligt, vælger vi endvidere at erstatte punktvisualisering med faktisk visualisering af objekterne. Vi svæver nu rundt og kigger på objekterne (en blanding af bøger og artikler), der hænger på væggen. Der hænger et par amerikanske artikler fra 1994 i øverste venstre hjørne af rummet. Vi klikker på den ene med 3D cursoren og der vises et kort abstract. Vi klikker videre på nogle andre artikler og en tynd bog også af nyere dato. Den ene artikel og bogen ser interessante ud. Vi trækker dem ned i vores virtuelle kurv. Vi springer tilbage til det oprindelige oversigtsbillede og beslutter os for at fortsætte opdagelsen i emneområdet medicin...

Mens brugere typisk vil være interesseret i at gå på opdagelse i informationsdatabasen kan den professionelle bruger anvende systemet til at overvåge databasen for uregelmæssigheder. Uregelmæssigheder vil typisk vise sig i form af enlige punkter langt fra andre punkter. Et eksempel på en søgning kunne være at sætte de tre dimensioner til henholdsvis årstal, materialetype og opstilling, hvor materialetype kan være trykt tekst, mikrokort, CD-rom, disketter, AV-materialer og opstilling kan være HHK bibliotek, Kongeligt bibliotek, DTU bibliotek m.v. Der vælges ingen afgrænsninger for de tre dimensioner. Fejlregistreringer som cd-udgivelser fra 1970, eller mikrokort fra 1994 (mikrokort anvendes ikke længere) vil vise sig som enlige prikker langt fra områder med større densitet af punkter. Brugeren vil kunne klikke med 3D-cursoren på "mistænkelige" punkter og derved kunne foretage en nærmere undersøgelse af de registrerede informationer.

Ovenstående eksempler illustrerer hvorledes VR brugergrænsefladen lagt ned over en stor informationsmængde muliggører, for det første, at brugeren kan gå på opdagelse i information og for det andet at brugeren kan percipere ellers skjulte mønstre i informationsmængden. Der er dog også situationer, hvor VR brugergrænsefladen ikke bidrager væsentligt til søgeprocessen. Det er, som førnævnt, i meget specifikke søgesituationer, hvor brugeren eksempelvis søger efter en bestemt bog, f.eks. ud fra en titel eller et forfatternavn. I en erkendelse heraf har vi valgt at undlade at diskutere, hvorledes traditionelle søgefaciliteter som f.eks. boolske operatorer, wildcards m.v. kan inddrages i ovenstående design. Der er dog intet i vejen for at også disse faciliteter indbygges i en VR brugergrænseflade.


7. Tilpasset design

I ovenstående afsnit er VR-bibliotekssøgesystemets design beskrevet uden hensyntagen til, hvad der faktisk er muligt at implementere. Designet er 'optimalt' og viser således, hvad vi mener, et sådant system i bedste fald skal kunne. Det er dette design, vi har forsøgt at anvende som kravspecifikation under den egentlige implementering af vores VR-system. Men det har naturligvis ikke været muligt at leve op til dette 'optimale' design under implementeringen, hvorfor det løbende er blevet tilpasset.

En del af design-ønskerne har det ikke været teknisk muligt at implementere. Det være sig pga. pc'ens manglende beregningskapacitet, pga. manglende udstyr eller pga. problemer med at få udstyret til at fungere som ønsket. Det har undervejs også vist sig, at dele af designet var mere person-ressourcekrævende end ventet. Nogle gange har implementeringsopgaven simpelthen bare været mere krævende, end design-ønsket antydede. Andre gange skulle der bruges kræfter på at implementere design-ønsker på en anden måde, end man umiddelbart havde forestillet sig. Og andre gange igen viste det sig at designet rent faktisk kom til at fungere uhensigtsmæssigt som det var og derfor skulle re-designes inden implementering. Dette ekstra tidsforbrug på visse design-implementeringer har også betydet, at en del andre design-ønsker helt er blevet bortprioriteret pga. tidsmangel. I det efterfølgende beskrives de designtilpasninger, som af flere grunde er opstået undervejs.

7.1 Tilpasning af biblioteksdatabasen
Hovedparten af oplysningerne i biblioteksbasen benyttes som beskrevet. Oplysninger om udlånt/ikke udlånt/reserveret er dog slet ikke med i database-udtrækket, og kan derfor selvsagt ikke anvendes. Oplysninger om serier, konferenceudgivelser og antologier anvendes ikke, da disse synes ret uinteressante i forhold til de øvrige data. Vi kan ikke have samtlige poster (bøger, artikler, cd-rom'er mv.) fra bibliotekets database med i vores VR-system, da disse hundredetusindvis af poster fylder adskellige gigabyte. Derfor har vi i VR-systemets database indlagt et udtræk fra bibliotekets database på knap 5000 poster.

7.2 Tilpasning af visualiseringsteknikkerne
Tilpasningen af designet sker indenfor rammerne af de beskrevne og udvalgte visualiseringsteknikker. Der skæres ikke så meget bort, at vi ikke længere udnytter teknikkernes fordele, ligesom der langt fra ændres så meget heri, at det kan komme på tale at finde nye og mere velegnede teknikker. Vores VR-biblioteksdatabase vil altså stadig overvejende være inspireret af Benedikts 3D Inforoom og enkelte idéer fra The Information Visualizer og Fairchild.

7.3 Tilpasning af rummets udseende
Brug af samtlige 6 vægge i rummet til punker og objekter kunne umiddelbart synes oplagt. For overskuelighedens skyld vælger vi dog kun at benytte 3 vægge. En anden grund hertil er af teknisk karakter, nemlig den ekstra beregningskraft, som visning af punkter og objekter på alle 6 vægge kræver af pc'en. Systemet designes til at have fire visualiseringstilstande: Pointmode, colormode, wallmode og swarmmode.

Pointmode viser biblioteksdatabasens indhold som punkter på tre af rummets vægge og bruges til at give overblik over, hvor de enkelte emner befinder sig.

Colormode har en matrix på 10*10 flade kvadrater i forskellige farvenuancer på hver af rummets vægge. Farverne går fra mørkegrøn til lysegrøn. Jo lysere, des flere emner (bøger, cd-rom'er, artikler) er der i det vægområde, kvadratet dækker. Colormode bruges til at give overblik over fordelingen af emner, og ligger der flere emner lige oven i hinanden, kommer dette til udtryk ved, at kvadratets farve bliver lysere heraf.

Wallmode giver ligeledes et godt overblik, men er dog noget mere detaljeret end pointmode. Det viser emnerne som rigtige objekter (bøger, cd-rom'er, artikler), i stedet for punkter, på rummets tre vægge. Brugeren kan vælge at få vist titel og forfatter på forsiden af objekterne og resten af oplysningerne om objektet kan fremkaldes på forsiden heraf ved at klikke på denne.

Svarmmode viser også basens poster som objekter, og kan vise oplysninger på objekterne ligesom i wallmode. Den store forskel i forhold til wallmode er, at objekterne svæver i rummet som en 'sværm', hvori brugeren kan flyve frit rundt.

Det optimale design tillod også valg af visualiseringstilstand for én væg uafhængigt af visualiseringstilstand for de andre vægge, f.eks. colormode på en væg og pointmode på en anden. Når kun 3 af de 6 vægge anvendes, er denne funktion mindre vigtig, hvorfor den ikke implementeres. I stedet laves det således, at valgt visualiseringstilstand gælder for alle tre vægge. En gitterfunktion, der viser en matrix (engelsk: grid) på væggene implementeres ikke af tids- og ressourcemæssige årsager. Dette betyder også, at proben ikke sættes til at bevæge sig i gittertrin - selvom dette ville være let at lave - men flyver i stedet glidende afsted.

Brugeren har mulighed for frit at vælge komprimeringsgraden for rummet. Vi har dog sat en standard komprimeringsgrad på 50%, således at emnerne vises på de midterste 50% af væggene (hvis pointmode) og i de midterste 50% af rummet (hvis swarmmode). Det, at der er 25% 'ubrugt' rum eller væg omkring emnerne, øger overskueligheden. Brugeren kan let ændre komprimeringsgraden, men bør max. sætte den op til 70%. Endelig er rummet, der måler 1000*1000*1000 punkter i WorldToolKit måleenheder, designet sådan, at man ikke kan komme helt hen til eller flyve igennem væggene. Det tætteste, man kan komme væggene, er 15 punkter. Herved undgår man at 'ryge ud af rummet', samtidig med at man ikke får væggene så tæt på, at man helt taber orienteringen og overblikket.

7.4 Tilpasning af objekternes udseende
Efter inspiration af Fairchilds AutoIcon skal emnerne fra biblioteksdatabasen i både pointmode (på væg) og swarmmode (i rum) kunne vises som objekter med attributter. Dog begrænses antallet af attributter pr. objekt. Farve (der viser emnets alder) og tykkelse (der viser emnets omfang/antal sider) anvendes ikke. Da oplysninger om, hvorvidt emnet er udlånt/ikke udlånt/reserveret, ikke er med i basen, vises dette ikke på objektets forside. Havde vi ønsket denne funktion, f.eks. som en rød plet på forsiden for udlånt, en gul for reserveret og en grøn for ikke udlånt, kunne vi have implementeret den ved for hver post (bog, CD-ROM mv.) i databasen at simulere denne udlånt/ikke udlånt/reserveret-tilstand. Men attributter som form (emner, der er bøger, vises som bøger, cd-rom'er vises som cd-rom'er osv.) og forside-tekst (basens oplysninger om emnet, der vises på forsiden af objektet) bevares.

At teksten kun vises på forsiden af objektet kan både være en fordel og en ulempe. Fordelen er, at objektet er (næsten) som i den virkelige verden. Ulempen er, at man skal hen til forsiden af objektet for at få oplysningerne om det. Dette klares dog ret let med 'point of interest flight'-funktionen, der forklares nærmere i det nedenstående afsnit om navigation. Et resumé kunne vises på objektets bagside, ligesom man i virkeligheden kan læse dette bag på en bog. Eller man kunne få resuméet at se, når man klikkede på objektet. Da biblioteksdatabasen ikke indeholder dette resumé, er denne funktion selvsagt ikke mulig at implementere.

Vi har valgt kun at vise titel og forfatter på hvert objekt. Ved at klikke på objektet kan man så vælge at få en automatisk flyvetur hen foran objektet og her få vist alle de oplysninger, der ligger i databasen herom, på forsiden af objektet. Som alternativ til at få informationerne vist på objektets forside, kan brugeren vælge at få dem vist i tekstvinduet, og derved spare en ikke ubetydelig ventetid pr. objekt, som han/hun ønsker information om. Er teksten, der skal vises på objektet, lang, da vises kun en del heraf i en læsbar størrelse, i stedet for at gå ned i tekststørrelse for at vise det hele. Brugeren kan ikke vælge at få vist hele teksten, hvis den ikke allerede er på objektets forside. Teksten kan dog vises i et tekstvindue. Er der mange bøger, cd-rom'er mv. i rummet kan brugeren både af plads- og hastighedsmæssige årsager slå tynde objekter til, således at en kasseformet bog bliver en helt flad firkant (der kun består af een polygon i stedet for seks).

7.5 Tilpasning af navigation
Ægte VR's nok største fordel i forhold til desktop VR er det fuldt omsluttende synsfelt, HMD'et giver. I et sådant system kan navigationen designes sådan, at synsfeltets orientering styres af ens hovedbevægelser, mens synsfeltets position kan styres af et joystick og proben i rummet af en 3D mus.

En ret afgørende teknisk begrænsning i vores VR-system skal findes i det faktum, at et HMD har været ganske vanskeligt at få fremskaffet. Så designet af navigationsmetoden er tilpasset et desktop VR-system på bedst mulig måde, idet al visualisering da i stedet kommer til at foregå på en desktop-computerskærm. Både synsfeltets orientering og position styres af en 2D mus, da 3D musen ved test viste sig at være uegnet til dette. Til gengæld kan navigation af proben med fordel klares med 3D musen. Proben kan alternativt styres vha. piletasterne frem/tilbage/højre/venstre og -/+ til op/ned. Dette viste der sig i sidste ende også at blive brug for, da 3D musen virkede ret ustabilt.

Point of interest (POI) flight vil kunne bruges sådan, at man kan klikke på et objekt, der har ens interesse, og så blive fløjet hen til det. Af tids- og ressourcemæssige grunde foregår flyvningen dog ikke, som i det optimale design, med logaritmisk hastighed, hvor det først går hurtigt og så langsomt lige inden ankomst, med mulighed for valg af andet objekt 'inden landing'. I stedet flyver man med en konstant hastighed fra ens position til POI-objektet. Der er ikke mulighed for nyvalg af objekt, før man står stille foran det valgte POI-objekt. Under flyvningen mod POI-objektet styres brugerens synsretning mod det valgte objekt, fordi det er et desktop VR-system. I et HMD-VR-system skulle man kunne kigge frit rundt undervejs mod POI-objektet.

Walking metaphor bruges også i vores desktop VR-system, således at man frit kan flyve rundt blandt objekter i den retning man ønsker, og se i den retning der interesserer en. Af tekniske årsager tvinges ens synsretning - igen i modsætning til i et ægte HMD-VR-system - i den retning, man bevæger sig. Først når man står stille, kan man se rundt i alle retninger. I systemet er også indbygget en funktion, der let bringer brugeren hen foran hver af de 3 vægge, således at disse kan iagttages. Uanset hvor man er, og i hvilken retning man ser, så kan man blot trykke på henholdsvis 1, 2 eller 3, hvorefter man automatisk flyves hen foran væg 1,2 eller 3.

Der er yderligere 2 automatiske funktioner, den ene nok lidt mere brugbar end den anden. Ønsker brugeren hurtigt og let at komme tilbage til startpositionen oppe i hjørnet med synsretningen skråt nedad, da klares det let ved at vælge hjem-funktionen med et enkelt tastetryk. Ønsker man en guidet tur rundt om objekterne i swarmmode, da kan man vælge guidet tur-funktionen.

7.6 Tilpasning af manipulation
Der er mulighed for at manipulere visualiseringen af rummet ved at vælge visualiseringstilstande eller variable for rummets 3 dimensioner. Men af tids- og ressourcemæssige grunde kan man ikke manipulere med selve dataene i rummet. Dvs. en bibliotekar kan ikke flytte, slette, oprette eller ændre data.

Da der er tale om et desktop VR-system, kommer brugerens visualiserings-manipulation selvfølgelig til at foregå via et almindeligt tastatur. Det tidligere optimale design fastslog, at den bedste brugergrænseflade ville være stemmegenkendelse. Teknisk kan dette dog endnu ikke fungere tilfredsstillende. Et alternativ kunne være et virtuelt tastatur vist i visualiseringen i HMD'et. Dette kunne dog godt tænkes at besværlig- og langsommeliggøre ens input, idet man kun kan klikke på én tast ad gangen. Så i forhold hertil er vores desktop VR-systems rigtige tastatur - der ikke kan betjenes, mens man har et HMD på - en klar forbedring.

Den transparente menuvæg' i selve visualiseringen, hvor brugeren kan få forskellige oplysninger om systemindstillinger og give input hertil, erstattes af tekniske årsager af et tekstvindue i en separat del af skærmen, udenfor det vindue, hvori selve rummet vises. Endelig bliver der ikke som tiltænkt mulighed for at trække og slippe objekter med en 3D-peger, klikke på akser og herved angive afgrænsninger, samt udvælge og lægge objekter ned i en virtuel kurv til senere brug.

7.7 Tilpasning af søgning
Oftest vil man forsøge at indsnævre det informationsområde, man foretager sin informationssøgning i. Dette kan ske ved at lade proben udpege eller omslutte det område, der er interessant. Dog kan man ikke ændre probens størrelse i 2D- eller 3D-form. Man kan altså vælge at få forstørret de emner, som proben har inde i sig, eller som probens spotlight indrammer på væggene, sådan at de herefter udgør hele rummet. Objekterne, som proben omslutter i swarmmode, lyser op, idet de får en hvid ramme omkring sig, således at brugeren let kan se at de er markeret af proben.

Proben er fra start af slået til, men man kan, hvis man ønsker det, slå den fra, således at den ikke kan ses i rummet. Der laves ingen fortryd-funktion, der lader brugerne springe tilbage til det forrige og større informationsområde, hvis man har forstørret et udvalgt område. Endelig vælger vi kun at vise start- og slutværdier på rummets akser, og ikke mellemindelinger. Dette ville let kunne kommer til at virke for gnidret eller småt, og således kræve, at man skal helt tæt på, for at kunne se aksernes tal/bogstaver. Under aksepilene vises navnet på dimensionens variabel.

Brugeren kan frit bestemme hvilke variable, der skal på hvilke akser, samt intervallet for disse variable. De kan enten ændres alle på én gang, eller de kan ændres enkeltvis, uden at de øvrige akser berøres heraf. Endelig kan man også vælge stantdardværdier for alle aksernes variable ved et enkelt tastetryk, hvorefter systemet automatisk vælger forfatter, forlag og år.


8. Beskrivelse af implementeringen

Vores designafsnit indeholdt ingen overvejelser om hvorledes programmet skal opbygges internt. Vores design behandler kun programmets visuelle udseende og funktionalitet. Det er til gengæld også gjort udførligt. Men vores fremgangsmåde strider mod de arbejdsmetoder, som vi gerne skulle have tillagt os tidligere på vores studie. Det er der selvfølgelig nogle grunde til.

For det første havde vi ingen anelse om, hvad det var, vi kastede os ud i. Denne opgave er resultatet af et studieprogram, og vi har således ikke modtaget undervisning i udvikling, strukturering eller programmering af et VR-system. Vi måtte selv tilegne os de fornødne kundskaber på den hårde måde. For det andet lægger vores softwareprodukt, WorldToolKit for Windows, op til, at udviklingen foregår som en prototyping-proces. Mere om vores problemer i kapitel 11.

I dette kapitel vi gennemgå opbygningen af programmet som det er blevet implementeret. Først beskrives den valgte softwareplatform, og hvad dette produkt indeholder. Dernæst gives der et overblik over hovedarbejdsfunktionerne i programmet. Dette sker ved hjælp af strukturdiagrammer, der er tegnet for at illustrere arbejdsprocesserne i systemet, og derfor ikke tager hensyn til den underliggende kode. Diagrammerne skal blot give et overblik over, hvorledes systemet arbejder på et abstrakt plan. Så følger der en nærmere beskrivelse af koden, der til sidst sluttes af med en beskrivelse af de vigtigste algoritmer i systemet. Selve programmet er at finde i bilag L.

8.1 Beskrivelse af softwareplatform
For at kunne realisere systemet var det nødvendigt at vælge en udviklingsplatform at implementere det på. Vores praktiske erfaringer med software- og hardware-indkøb er beskrevet i kapitel 11, og her vil vi kun beskrive det valgte produkt, Sense8 WorldToolKit

Sense8 WorldToolKit (herefter blot WTK) er ikke en platform, hvorpå man uden videre kan udvikle et VR-system. WTK består nemlig "kun" af et bibliotek med over 400 funktioner skrevet i C. WorldToolKit findes til en række forskellige platforme, fra den største, en version til Silicon Graphics-maskiner i millionklassen, og helt ned til en Windows-version. Da der kun er tale om C-funktioner, er koden praktisk taget direkte portabel mellem de forskellige platforme.

For at kunne udnytte C-funktionerne kræves der en compiler. WTK fungerer med en række forskellige compilere, herunder Microsoft Visual C++ 2.0. Det specielle ved denne version af MS VC++ er, at den er en 32 bit compiler, hvilket er mindstekravet til WTK. Men det forudsætter igen, at man foretager kompileringen på et 32 bit operativsystem. Til dette benyttes Windows NT 3.5. Men Windows NT er et ressourcekrævende operativsystem, så for at kunne afvikle koden hurtigere, bruges Windows 3.11 med 32 bit extensions, der på en række områder er bedre optimeret hastighedsmæssigt end Windows NT. Mere om vores kvaler hermed i kapitel 12. På trods af at vi har benyttet en C++ compiler, er programmet implementeret i C, jævnfør at WTK's biblioteksrutiner er C-funktioner. Biblioteksfunktionerne i WTK er opdelt i en række grupper:

8.2 Strukturdiagrammer
Dette afsnit er med for at beskrive systemets hovedelementer på et abstrakt, implementerings- og kodeuafhængigt plan, således at man kan danne sig et overblik over systemet. For at illustrere de underliggende arbejdsopgaver, har vi lavet nogle strukturdiagrammer. Heri bliver hovedelementerne beskrevet, uden at der er taget hensyn til den underliggende kode eller den rækkefølge, de i praksis bliver afviklet i.

Strukturdiagrammerne består af fire diagrammer, der indeholder en række kasser med tekst i. De er placeret i en pyramideform og forbundet med pile der alle peger ned. Kassen på toppen beskriver arbejdsopgaven på et meget abstrakt plan. Jo længere man bevæger sig ned i pyramiden, des mere konkret bliver beskrivelsen af arbejdsopgaven. En arbejdsproces med rektangler placeret under sig bliver således yderligere uddybet i de underliggende kasser. Det er med vilje, at der blandt de illustrerede arbejdsopgaver ikke findes nogle funktioner til simpel opdatering af skærmbilledet, dvs. ændringer af alle objekters og vægges udseende. Denne arbejdsopgave løses nemlig automatisk af WTK og ligger implicit i animationsløkken, som bliver beskrevet senere.

Grundliggende kan systemet inddeles i fire moduler: (A) Databasesøgning, (B) Tegn rum, (C) Tegn objekter, og (D) Reager på input. I nogle af diagrammerne indgår der en kasse med to lodrette streger. Det betyder at denne arbejdsopgave bliver uddybet i et andet modul, hvor den vil befinde sig som den øverste arbejdsopgave.

(A) Database-søgning.
Dette modul finder poster frem fra databasen ud fra givne afgrænsninger og variable. Først gennemsøges hele databasen for at udvælge alle poster, der ligger indenfor de afgrænsninger, der er blevet givet til henholdsvis (1) x-variablen, (2) y-variablen og (3) z-variablen. Afgrænsninger og variable kommer fra modul (D). Resultatet af søgninger er tre forskellige mængder af poster. Derefter (4) findes fællesmængden af de tre delmængder. Til sidst (5) tegnes rummet ud fra denne fællesmængde. Tegn rum (5) uddybes i modul (B).


Figur 9: Database-søgning

(B) Tegn rum.
Dette modul kan deles op i to store underopgaver. Det er dels tegning af vægge og hvad der hører til koordinatsystemet, og dels tegning af informationer i rummet. Rummet tegnes ved (6) at placere en probe midt i kuben, og så (7) lave dens skygger ude på væggene. Så (8) sættes pile på væggene, (9) variabelnavne sættes på, og til sidst (10) afgrænsninger. Informationer i rummet kan enten bestå af objekter (11) der uddybes i modul (C), eller også kan det bestå at af et pointmode/colormode, hvor (12) textures til de tre vægge først skal beregnes, for derefter (13) at blive sat ind på de tre vægge. Koordinater til, hvor objekterne skal placeres, kommer enten fra modul (D), eller også benyttes der en standardsøgning.


Figur 10: Tegn rum

(C) Tegn objekter.
Først oprettes objekter, så placeres de i rummet, for til sidst at få sat textures på. Oprettelsen af objekterne kan opdeles i tre underfunktioner, hvor henholdsvis bøger (14), artikler (15) og cd'er (16) oprettes. Derefter kan de blive placeret enten hængende ude i rummet som en sværm (17), eller på væggene (18). Oprettelsen er afhængig af om de skal placeres som sværm eller på væggene. Placering på væggene giver tre gange så mange objekter som sværm.


Figur 11 Tegn objekter

Så sættes der textures på. Cd'er får blot deres texture sat på uden videre (19), medens textures til artikler og bøger først skal genereres. Det sker ved at baggrunden til bogen laves (20), hvorefter titler og lignende sættes på (21). Disse informationer er lig den mængde som blev fundet ud fra databasesøgningen. Til sidst sættes der også textures på bøger (22).

(D) Reager på input.
Der kan gives to forskellige typer input til systemet. Den ene er tekstbaserede kommandoer, som indtastes i en dialogboks.. Den anden type er input givet via et en hardwareenhed (mus, joystick eller 3D-mus). Hvis der er givet en tekstkommando, kan den enten (23) foretage en ændring af variabeltyper, (24) lave en ændring af afgrænsninger for variable eller (25) et skift af tilstande. Alle disse tre funktioner fører endvidere frem til et kald af de øvrige moduler, for at der kan pågå en ny databasesøgning, eller rummet eller objekter kan blive gentegnet. Ud over disse funktioner varetages også en lang række reaktioner på tastaturinput, der dog for overskuelighedens skyld er udeladt i ovenstående figur.


Figur 12: Reager på input

Hvis man har foretaget et navigationsinput, så kan man (26) flyve til et objekt, flytte proben (27), skifte position i rummet (28) eller flyve tilbage til udgangspositionen (29).

8.3 Programbeskrivelse
I dette afsnit vil vi beskrive selve implementeringen af systemet. Programmeringen har i vid udstrækning været baseret på brug af biblioteksfunktioner, men det betyder ikke, at vi har undgået at programmere en hel del selv. Programmet kan opdeles i to dele: En hovedfunktion, der varetager opbygning, initialisering og igangsætning af universet, og en afviklingsfunktion, der kontinuerligt udføres under afviklingen af universet. Med udgangspunkt i disse to dele vil vi beskrive programmets opbygning for at kunne vise, hvorledes vi har udnyttet biblioteksfunktionerne. Beskrivelsen af de to programdele er lavet som pseudokode, suppleret med kommentarer.

8.3.1 Startfunktion
Initialisér viewpoint opretter og initialiserer brugerens viewpoint i universet. Viewpointets startposition er oppe i et af rummets "loftshjørner", mens orienteringen peger mod rummets centrum, således at man hænger oppe og kigger skråt ned på de 3 vægge i rummet, hvor data vises.

Det virtuelle Bibliotek hovedfunktion
{
	Initialisér viewpoint
	Skab rum
	Skab probe
	Skab skygger
	Skab lys
	Gennemsøg database
	Tegn rum
	Initialisér sensorer
	Klargør univers
	Start univers

	Hvis: Afslut programmet
		Slet univers
}

Skab rum opretter rummet som en kube, med en størrelse på 1000 x 1000 x 1000 enheder. Enhederne er WTKs egne. Væggenes farve sættes til forskellige nuancer af blå således, at man kan se overgangene mellem væggene.

Skab probe opretter proben som en transparent kube, hvor kun probens kanter vises. Proben placeres i rummets centrum og størrelsen på probens sider sættes til 1/10 af rummets sider.

Skab skygger opretter probens skygger på de tre vægge i rummet, hvor data visualiseres. Skyggerne ses som gennemsigtige kvadratiske firkanter på væggene. En skygge laves som en kube uden dybde (svarende til en firkant), og vises ligesom proben transparent med synlige kanter.

Skab lys sætter rummets baggrundslys til maksimum (1.0). Det gør, at der vil være et ensartet ikke-retningsorienteret lys i hele rummet. Der anvendes p.t. ingen retningsorienterede lyskilder, da de har negativ indflydelse på programmets afviklingshastighed.

Gennemsøg database opsætter nogle standard søgevariable og afgrænsninger for rummets 3 akser, og udfører derefter en søgning i databasen. Resultatet af søgningen skrives i en fil, kaldet tagfile.

Tegn rum tegner resultatet af den seneste søgning i rummet. Først tegnes akser, med tilhørende variabeltekster og afgrænsningstekster. Derefter gennemløbes tagfile. For hvert fundet objekt findes dets værdier for de tre variable, der indgik i søgningen. Ud fra de tre værdier og de valgte afgrænsninger beregnes objektets placering i rummet. Er pointmode valgt tegnes objektet som et punkt på væggen. Er swarmmode valgt tegnes objektet som et bog, artikel eller cd-rom hængende i rummet. Er wallmode valgt tegnes objektet ligeledes som en bog, artikel eller cd-rom, dog placeret på væggene. Er colormode valgt, indgår objektet i en farvematrix på væggen. Initialisér sensorer initialiserer mus, joystick og 3D mus. Først kontrolleres om der er tilsluttet en mus til systemet. Hvis ikke, så gives en fejlmeddelelse, og programmet standses. Derefter undersøges om systemet har et joystick. Hvis det er tilfældet, så tilknyttes joysticket til brugerens udsyn, hvis ikke, så tilknyttes musen til brugerens udsyn. Endelig undersøges om systemet har en 3D mus. Hvis ikke, så gives en fejlmeddelelse og programmets standses. Hvis ja, tilknyttes 3D musen til proben.

Klargør univers er et WorldToolkit funktionskald, der initialiserer universet og allokerer den nødvendige hukommelse for afviklingen.

Start univers er også et WorldToolkit funktionskald, der igangsætter afviklingen af universet. Afviklingen standses med Slet univers funktionskaldet, der gives i brugerens afviklingsfunktion (beskrevet nedenfor).

Slet univers er endnu et WorldToolkit funktionskald, der sletter universet fra hukommelsen efter brug.

8.3.2 Afvikling
Afviklingen af universet foregår i såkaldte simulationsløkker (engelsk: simulation loops). Når afviklingen af universet igangsættes med Start univers kommandoen gennemløbes simulationsløkken kontinuerligt, indtil universets afvikling standses med Stop univers kommandoen. I een simulationsløkke udføres følgende opgaver:


Figur 13: En simulationsløkke

Først aflæser WorldToolKit samtlige sensorer, der er initialiseret i hovedprogrammet. Det vil i dette tilfælde sige mus, joystick og 3D-mus. Herefter afvikles en brugerdefineret handlingsfunktion (action function), som indeholder den del af Det virtuelle Bibliotek programkoden, der skal afvikles i hver simulationsløkke. Det gælder f.eks. kontrol af, om brugeren holder sig indenfor rummets vægge, kontrol af om proben holder sig indenfor koordinatsystemets grænser, kontrol af keyboardinput, undersøgelse af om proben skal 'eksploderes' osv. Herefter opdaterer WorldToolKit objekter i forhold til sensorinput. I Det virtuelle Bibliotek sammenhæng vil det sige, at probens position opdateres i forhold til bevægelser med 3D musen. Herefter udføres evt. opgaver tilknyttet objekter (object tasks). Det er særlige brugerdefinerede opgaver, der relaterer sig til enkelte objekter. Denne facilitet anvendes ikke i Det virtuelle Bibliotek. Endelig genererer WorldToolKit ud fra sensorinput et billede af universet, baseret på brugerens aktuelle position og orientering i universet. Den rækkefølge, som de fem moduler er stille op i, er ikke nødvendigvis endelig. Rækkefølgen, hvori de tre midterste moduler afvikles, er nemlig ligegyldig, set ud fra WorldToolKit´s synsvinkel.

Ved sammenligning mellem simulationsløkken fra WTK og The Cognitive Coprocessor (CC) (afsnit 5.1) fra The Information Visualizer (IV) kan man finde en hel del fællestræk Sensorer aflæses i WTK har ingen direkte parallel, idet den er en ret simpel funktion, der ikke indgår som en hovedbestanddel i IV. Den er der selvfølgelig, men den er uvæsentlig. Kaldet af handlingsfunktioner i WTK er lidt svær at føre direkte over på CC, men den befinder sig blandt opgaverne i den nedre del af User Discourse Machine. Opdateringen af objekter i forhold til sensorinput kan sammenlignes med navigation, styring af rummet og styring af objekter i CC.

En vigtig del af CC er de autonome søgeagenter, der kører uafhængigt af systemet. I WTK er det også muligt at sætte en række arbejdsopgaver i gang, men dog ikke så de kører uafhængigt af animationsløkken. Opgaverne skal være afsluttet før animationsløkken kan gå videre til næste trin. Alligevel kan der til en vis grad sættes lighedstegn mellem Søgeagenter i CC og Opgaver tilknyttet objekter udføres i WTK.

Dannelsen af universet i WTK kan sammenlignes med visningskø, og til en vis grad med govenor. Dog findes der ingen govenor i WTK, idet der ikke tages hensyn til, hvor mange bileder der skal generes per sekund - de bliver blot lavet, så hurtigt de kan. Hvis man ønsker det, så kan man godt implementere en govenor i WTK, men det bliver i så fald som en af de brugerdefinerede opgaver.

8.3.3 Afviklingsfunktionen
Den brugerdefinerede handlingsfunktion og udførslen af funktioner tilknyttet objekter er de værktøjer som programmøren har for at påvirke afviklingen af universet. Aflæsning af sensorer, opdatering af objekter i forhold til sensorinput og generering af billede af universet varetages automatisk af WorldToolkit. Afviklingsfunktionen er gennemgået nedenfor (kun de vigtigste funktioner er medtaget).

Det virtuelle Bibliotek afviklingsfunktion
{
Hvis_indtastning
	tast = h
		Flyt viewpoint hjem
	tast = q
		Kør universets afslutningsfunktion
	tast = c, x, y eller z
		Aflæs input til x-, y- og/eller z-aksen
		Gennensøg databasen
		Slet alle objekter i rummet
		Gentegn rummet
	tast = i	
		Udskriv information om position, orientering,
		antal polygoner og framerate
	tast = s
		slår korte titler til/fra
	tast = t
		slår lange titler til/fra
	tast = piletast eller +/-
		flyt probe 10 enheder i ønsket retning
	tast = m
		Skift tilstand
	tast = f
		Skift kompressionsfaktor
Hvis_indtastning_slut

Hvis_mus
	museknap = venstre og
		position på skærm = øvre del
			flyv frem i synsretning
		position på skærm = nedre del
			flyv tilbage i synsretning
		position på skærm = venstre del
			drej til venstre
		position på skærm = højre del
			drej til venstre
		museknap = højre
			og position på skærm = venstre del
				rotér venstre om z-aksen		
		museknap = højre og
			position på skærm = højre del
				rotér højre om z-aksen
	museknap = midterste og markør peger på et objekt
		hvis foran objekt
			vis fuld titel
		ellers
			beregn rute
			flyv til objekt
	museknap = højre
		position på skærm = øvre del
			flyv op
		position på skærm = nedre del
			flyv ned
Hvis_mus_slut

Hvis_3D_mus
	museknap = venstre
		Identificer afgrænset område
		Tegn rum med nye afgrænsninger
Hvis_3D_mus_slut
	
Hold synsfelt indenfor rum
Hold probe indenfor afgrænsninger
Opdatér probens skygger
}
I Det virtuelle Bibliotek anvendes funktioner tilknyttet objekter ikke. Al afviklingsrelateret er placeret i den brugerdefinerede afviklingsfunktion. Afviklingsfunktionen varetager input fra keyboard, mus og 3D mus. Dertil kommer en række kontroller og opdateringer af probe, probens skygger, brugerens viewpoint m.v.

8.3.4 Hvis_indtastning
Tast = c, x, y eller z: Indtastning af nye søgevariable og afgrænsninger. Aflæs input til x-, y- og/eller z-aksen opsætter en dialogboks, hvor søgevariable og afgrænsninger kan indtastes for henholdsvis X,Y og Z aksen. Gennemsøg databasen foretager en søgning i databasen med en eller flere søgevariable. Slet objekter sletter først alle objekter i rummet og til sidst vil funktionen gentegn rum ud fra seneste søgning gentegne rummet.

Tast = t: Titler på objekter slås til/fra. Med titler forstås oplysninger om objekterne: forfatternavn, titel, undertitel, udgiver, udgivelsessted osv. En variabel bestemmer om titler vises på bøger eller ej. Af plads- og hastighedsmæssige årsager kører Det Virtuelle Bibliotek som udgangspunkt uden titler på objekter. Således fylder én titelforside mere end 600K. Da databasen er på 5000 poster vil en komplet samling titelforsider kræve en diskkapacitet på omkring 3 gigabyte.

Tast = s: Korte titler på objekter slås til/fra. Som forgående, dog vises kun forfatternavn og bogens titel. Funktionen er mindre krævende end den foregående og er derfor som udgangspunkt slået til. Én kort titelforside fylder omkring 60K. Samtlige korte titelforsider fylder omkring 300 MB, altså en 1/10 af de komplette titelforsider.

Tast = i: Diverse informationer om universet udskrives. Position og orientering er viewpointets placering og retning i universet. Polygoner er antal polygoner som dette univers består af. Framerate fortæller hvor mange billeder i sekundet dette univers afvikles med.

Tast = h: Kalder funktionen flyt viewpoint hjem, der flytter viewpointet tilbage til rummets udgangsposition. Funktionen finder først brugerens aktuelle position og orientering i universet. Derefter findes startpositionens position og orientering. Med udgangspunkt i disse to punkter i universet beregnes vha. interpolation en række mellemliggende punkter, som flyvningen skal passere for at komme fra den aktuelle position til startpositionen. Antal af mellemliggende punkter beregnes som: (afstanden mellem aktuel position og startposition) / 25. I praksis betyder det at flyvetiden er afhængig af afstanden mellem aktuel position og startposition. Som rummet er konstrueret p.t. kan man maximalt komme til at flyve 60 punkter, hvilket i tid svarer til omkring 6 sekunder. Oftest vil man dog opleve at flyveture tager omkring 3-4 sekunder.

Tast = m: Kalder funktionen skift tilstand, der tillader brugeren at vælge mellem følgende visualiseringstilstande: Pointmode, wallmode, swarmmode og automode. Ved ændring af tilstand gentegnes rummet.

Tast = f: Kalder funktionen skift kompressionsfaktor, der bestemmer hvor stor en del af rummet koordinatsystemet udgør. Kompressionsfaktoren er som udgangspunkt sat til 0.5, hvor 1 svarer til at koordinatsystemet udfylder hele rummet.

Tast = piletast eller +/-: Kalder funktionen flyt probe 10 enheder i ønsket regning. Pil til højre/venstre flytter proben på x-aksen, pil op/ned på z-aksen og +/i på y-aksen.

8.3.5 Hvis_mus
Funktionen Museknap = venstre og reagerer forskelligt afhængigt af hvor på skærmen markøren er placeret. Hvis den er placeret i den øvre eller nedre del af skærmen, vil viewpointet blive flyttet enten frem eller tilbage. Hvis den er placeret i den venstre eller højre del af skærmen vil viewpointet dreje til venstre eller til højre. Viewpointflytningerne fungere samtidig, således at man kan eks. flyve frem samtidig med at man drejer til venstre. Hvis højre knap samtidig trykkes ned, vil viewpointet rotere til venstre eller højre, afhængigt af om markøren befinder sig i venstre eller højre del af skærmen.

Funktionen museknap = højre. Hvis højre knap på musen trykkes ned, vil viewpointet bevæge sig op eller ned (langs viewpointets y-akse), afhængigt af om markøren befinder sig i den øvre eller nedre del af skærmen.

Funktionen Museknap = midterste og markør peger på et objekt. Peger brugeren på et objekt, der befinder sig umiddelbart foran brugerens viewpoint, så antager funktionen at brugeren ikke er interesseret i at blive transporteret til objektet, men isteret er interesseret i yderligere oplysninger om objektet og kalder derfor funktionen vis fuld titel. Hvis brugeren derimod peger og klikker på et objekt, som han ikke befinder sig umiddelbart foran, så udføres funktionerne beregn rute og flyv til objekt, der flyver brugeren hen til det objekt der blev peget/klikket på.

Vis fuld titel tillader brugeren at pege og klikke på et objekt, der kun vises med kort titelside og få vist den lange titelside. Først beregnes hvilket objekt der er klikket på. Derefter undersøges om lang titelside tidligere er blevet genereret som texture, og derfor allerede findes på harddisken. Hvis ja, hentes titelside og tilknyttes objektet. Hvis nej, genereres ny titelside, den gemmes på disken og tilknyttes objektet. Førstnævnte proces tager ca. 6 sekunder, mens sidstnævnte tager ca. 12 sekunder

Beregn rute og flyv til objekt tillader brugeren med musemarkøren at pege og klikke på et objekt, for derefter at flytte viewpointet til det valgte objekt. Først beregnes hvilket objekt brugeren har peget på. Position og orientering for brugerens aktuelle viewpoint og objekt findes og de mellemliggende punkter på ruten beregnes vha. interpolation (der anvendes samme metode som ved home funktionen). Det endelige viewpoint position korrigeres i forhold til objektet således at objektet vises i fuld størrelse.

Funktionen museknap = højre bevæger viewpointet op eller ned (på y-aksen).

8.3.6 Hvis_3D_mus
Funktionerne identificer afgrænset område og tegn rum med nye afgrænsninger tillader brugeren at udvælge en delmængde af rummet vha. proben. Først undersøges hvilken visualiseringstilstand, der er aktivt. Er der valgt swarmmode beregnes hvilke objekter, der befinder sig indenfor probens rammer. Disse objekter udvælges og vises i et nyt virtuelt bibliotek. Er der valgt pointmode eller wallmode spørges hvilken skygge / væg (XY, XZ eller YZ), der skal danne udgangspunkt for udvælgelsen. Herefter beregnes hvilke objekter, der befinder sig indenfor skyggens rammer, og disse objekter vises nu i et nyt virtuelt bibliotek. Bemærk at i swarmmode indsnævres min. og max. værdier for alle tre søgevariable, når proben eksploderes, mens point- og wallmode kun medfører indsnævring af min. og max. værdier for to søgevariable.

8.3.7 Andre funktioner
Hold synsfelt indenfor rum kontrollerer, at viewpointets position holder sig indenfor rummet. Rummets dimensioner er 1000 x 1000 x 1000 punkter, med 0,0,0 som centrum. Funktionen kontrollerer, at X,Y og Z koordinaterne for viewpointet holdes i intervallet -485 til +485. Overskrides disse værdier korrigeres viewpointets position. De 15 punkter i margen er beholdt for at undgå at brugeren midlertidigt bryder gennem væggene, hvilket ville være muligt som følge af at positioneringen og kontrolleringen af positionen foretages af to forskellige funktioner, og ikke på samme tid. Det burde være unødvendigt, men sætter man intervallet fra -499 til 499, vil man opleve, at man et kort øjeblik kan bryde gennem rummets vægge for derefter at blive smidt tilbage igen.

Hold probe indenfor afgrænsninger kontrollerer, at probens position holder sig indenfor koordinatsystemets rammer, hvis størrelse varierer med komprimeringsfaktoren (se ovenfor).

Opdatér probens skygger opdaterer probens skygger på de tre 3 vægge i rummet, hvor data vises. Dette gøres ved at opdatere positionen på skyggerne i forhold til proben. For skyggen på XY væggen sættes positionen til X = Probe(X), Y = Probe(Y) og Z = 499. For skyggen på XZ væggen sættes positionen til X = Probe(X), Y = -499 og Z = Probe(Z). For skyggen på YZ væggen sættes positionen til X = -499, Y = Probe(Y) og Z = Probe(Z).

8.4 Beskrivelse af udvalgte algoritmer
I dette afsnit beskrives udvalgte algoritmer fra Det virtuelle Bibliotek. Af plads- og tidsmæssige årsager har vi udvalgt seks, som vi mener ikke bare er interessante i en datalogisk sammenhæng, men som også anskueliggører interessante problemstillinger i Virtual Reality.

8.4.1 Visning af tekst i Det virtuelle Bibliotek
Som man vil bemærke ved brug af Det virtuelle Bibliotek, anvendes tekst flittigt til at informere brugeren om aktuelle søgevariable og afgrænsninger, forfatternavn, titel, emneord m.v. WorldToolKit har en indbygget tekstfacilitet, der kan generere og vise tekst i universet. Teksten genereres som rigtige geometriske objekter, stykket sammen af mange små flader (polygoner). Selvom denne metode er "korrekt", er den samtidig meget beregningsmæssigt krævende. Et bogstav kan fylde 20 polygoner eller mere og et ord på 6 bogstaver fylder nemt 150 polygoner. Sammenholdes dette med, at den anvendte hardware, som Det virtuelle Bibliotek p.t. afvikles på, ikke er gearet til at håndtere modeller på meget mere end 700-800 polygoner, så skal der ikke skrives mange ord før end afviklingen bliver uacceptabelt langsom. På den baggrund må man konkludere, at den indbyggede tekstfacilitet i WorldToolkit kun er anvendelig, såfremt man har et meget begrænset behov for inkludere tekstobjekter i sin tilstand. Da en væsentlig del af informationen i Det virtuelle Bibliotek er af tekstuel karakter, var vi derfor tvunget til at finde en mindre beregningskrævende metode til generering af tekst.

I stedet for at vise en vilkårlig tekst som rigtige geometriske objekter sammenstykket af polygoner, kan tekst vises vha. textures (bitmaps). Hvor førstnævnte metode tegner hver eneste lille krumning på hvert bogstav i hvert et ord i hvert eneste simulation loop, så forudsætter sidstnævnte metode, at teksten er tegnet i forvejen, og tager sig derfor kun af at placere den allerede færdigtegnede tekst i universet. Eller sagt på en anden måde, den væsentligste forskel på metoderne er, at førstnævnte behandler en sætning som mange små individuelle elementer (polygoner), mens sidstnævnte behandler en sætning som ét element (polygon). Fordelen ved sidstnævnte metode er naturligvis en voldsom hastighedsoptimering.

Men anvendelsen af textures til generering af tekst er desværre heller ikke uden problemer. Det væsentligste problem er, at man ikke kan forudsige hvilke tekster, der er behov for at vise under afviklingen. Eksempelvis kan afgrænsninger på søgevariable antage uendeligt mange værdier. Det betyder, at man ikke, en gang for alle, kan generere alle tekster som textures vha. et tegneprogram. Man er nødt til at have en algoritme, der løbende under afviklingen er i stand til at konvertere tekststrenge til textures!

Algoritme til konvertering af tekststrenge til texture-filer
{
Initialiser array med baggrundsfarve

Gentag: Indtil der ikke er flere bogstaver i strengen
	find bogstavets ascii-værdi
	åben bogstavfil med tilsvarende ascii-værdi

	Gentag: Indtil der ikke er flere pixels i højden

		Gentag: Indtil der ikke er flere pixels i bredden
			Læs bogstavfil
			Hvis pixelværdi i fil = 0
				giv pixel i array forgrundsfarve
			ellers
				giv pixel i array baggrundsfarve
		Gentag_slut

		Ajourfør position
	Gentag_slut

	Luk bogstavfil
	Gem texture i fil
Gentag_slut
}

Vi har konstrueret denne algoritme således, at den ud fra en input-tekstreng genererer en texturefil svarende til indholdet af input-tekststrengen. Algoritmen forudsætter, at alle relevante tegn i ascii tabellen ligger som textures på disken. Algoritmen gennemløber samtlige tegn i inputstrengen og "appender" hvert tegns texture til det totale texture. Mere præcist udføres algoritmen som følger: Først initialiseres det array, der undervejs i genereringsprocessen skal indeholde texturet. Arrayet initialiseres med en værdi svarende til baggrundsfarven på texturet. Herefter gennemløbes input tekststrengen. For hvert tegn i strengen udføres følgende opgaver:

  1. Navnet på det pågældende tegns texturefil findes og åbnes. Filnavnet svarer til tegnets ascii kode.
  2. Tegnets texturefil indlæses.
  3. Indholdet af tegnets texturefil kopieres over i texture_array.
  4. Den horisontale position i texture_array tælles op med bredden af det netop indlæste tegn.

Når samtlige tegn er gennemløbet gemmes indholdet af array´et i en fil. I Det virtuelle Bibliotek findes denne algoritme i funktionen convert_string2texture. En arbejdsproces i denne forbindelse var selvfølgelig, at vi måtte tage et helt ascii-tegnsæt og konvertere det bogstav for bogstav til et grafikformat, som WTK accepterer (Targa).

8.4.2 Positionering af objekter i et 3D rum
En anden central problemstilling er, hvorledes man ud fra en vilkårlig bogs (eller artikels) oplysninger om titel, forfatter, emneord mv. placerer den i et tredimensionelt rum. Den helt grundlæggende tanke bag Det Virtuelle Bibliotek er netop, at objekters placering i rummet skal afspejle objektets karakteristika, men hvordan omformes f.eks. en titel til et sæt koordinater i et tredimensionelt rum? Problemet løses nemmest ved at opdele det i to delproblemer:

  1. Skitsering af en algoritme, der kan foretage en reversibel og entydig omregning af tekststrenge til ascii talkoder.
  2. Skitsering af en algoritme, der kan foretage en reversibel og entydig omregning af tekststrenges ascii talkoder til et koordinat i et tredimensionelt rum.

Fra tekststrenge til ascii talkoder
For at placere fundne poster i et af koordinatsystemerne på væggene eller i rummet skal programmet sammenholde den aktuelle posts værdi med de valgte afgrænsninger. Er den valgte søgevariabel f.eks. årstal, er det ikke noget problem. Hvis bogen er udgivet i 1985 og minimumværdien er sat til 1960 og maksimumværdien er sat til 1990, så er det ingen kunst at beregne, at bogen i et koordinatsystem fra 0-30 vil ligge som nr. 25. Er søgevariablen derimod forfatternavn, er løsningen ikke så ligetil. En løsning kan dog udformes, hvis man opfatter tekststrenge som tal i et base 256 talsystem, svarende til ascii-tabellens 256 tegn. Algoritmens funktion bliver at omregne et tal fra et base 256 talsystem til et tal i et base 10 talsystem.

Mere specifikt skal algoritmen gennemløbe en tekststreng. Den skal beregne en ascii talkode, baseret på 1) de tegn som indgår i strengen og 2) deres position, således at første tegn i strengen tæller med 1, næste tegn med 1/256 del, næste tegn med 1/(256*256) osv. Eksempel: Søgevariabel er sat til forfatter. Den aktuelle forfatter er "Schlesinger, Arthur M.", minimumværdi er "A" og maksimalværdi er "Z".

Aktuel 10 talværdi = 83 x 1 + 67 x (1/256) + 72 x (1/(256x256)+ .. + .. = 83,262821928907

Minimumværdi - "A" kan efter samme fremgangsmåde udregnes til 65 og maksimalværdi - "Z" til 90. I Det Virtuelle Bibliotek findes denne algoritme i funktionen convert_string2number og vises nedenfor i pseudokode:

Algoritme til konvertering af tekststreng til talkode
{
	Talkode = 0
	Gennemløb = 0
	Hvis variabel er størrelse, base eller år
		Konverter direkte til tal
	Ellers
		Gentag: Indtil der ikke er
		flere bogstaver i strengen

			Bogstav = Bogstavets ascii-værdi
			Hvis: Bogstavet er et lille bogstav
				Konverter det til stort bogstav
			Talkode = Talkode + (Bogstav * 256-Gennemløb)
			Gennemløb = gennemløb + 1

		Gentag_slut
	Hvis_variabel_slut
}

Fra ascii talkoder til rumkoordinater
Når først en titel, forfatternavn, emneord og så videre er omregnet til en alfabetisk talkode er det forholdsvis smertefrit at omregne talkoden til et koordinat i rummet. I ovenstående eksempel svarede forfatternavnet "Schlesinger, Arthur M." til værdien 83,26, mens minimumværdi var "A" svarende til værdien 65 og maksimalværdi "Z" svarende til værdien 90. Rumkoordinatet for "Schlesinger, Arthur M." kan udregnes således:

rumkoordinat = ((talkode - minimumværdi) / (maksimalværdi - minimumværdi) * ( rumlængde - rumstart) * kompressionsfaktor

Er rummets kompressionsfaktor = 1/2 vil rumkoordinat for "Schlesinger, Arthur M." kunne udregnes således:

rumkoordinat = ((83,26 - 65) / (90 - 65) * 1000 - 500) *0,5 =115

Det resulterende rumkoordinat vil med kompressionsfaktor 1/2 ligge mellem -250 og 250, hvor 0 er midten af rummet.

8.5 Visualiseringstilstande
Det virtuelle Bibliotek understøtter fire tilstande (samt automode): pointmode, swarmmode, wallmode, og colormode. Alle fire tilstande tager udgangspunkt i ascii talkoderne beskrevet i foregående afsnit, men talkoderne behandles forskelligt. De følgende afsnit beskriver algoritmerne for de fire visualiseringstilstande.

8.5.1 Pointmode
I pointmode vises rummets objekter som punkter på tre af væggene (2 vægge plus gulvet). Dette kunne tænkes gjort på to måder: hvert objekt kunne være et grafisk objekt (en polygon), eller alle objekter kunne vises som en texture på ét objekt. Den første løsning er den simpleste, men den er desværre uanvendelig ved store mængder objekter, hvilket netop er, hvad pointmode skal bruges til. Derfor har vi valgt at benytte løsning nummer to: at generere et texture for hver væg.

De tre textures genereres ved, at programmet for hvert objekt, der skal med i rummet, beregner de alfabetiske talkoder for hver af de tre variable som beskrevet tidligere, omregner talkoderne til en plads i hvert af de tre array´er og indsætter et hvidt punkt på denne plads. Når samtlige objekter, der skulle med, er plottet ind, gemmes de tre textures, og der genereres tre objekter til at holde de tre textures. Omregningen fra alfabetiske talkoder til texturekoordinater minder meget om omregningen til rumkoordinater (beskrevet tidligere):

texturekoordinat_x=(talkode_x-minimumværdi_x)/(maksimalværdi_x - minimumværdi_x) * (vægstørrelse-2)+1
texturekoordinat_y=(talkode_y-minimumværdi_y)/(maksimumværdi_y - minimumværdi_y) * (vægstørrelse-2)+1
texturekoordinat_z=(vægstørrelse-1)-(talkode_z-minimumværdi_z)/(maksimalværdi_z - minimumværdi_z) * (vægstørrelse-2)

Det er nødvendigt at invertere z-koordinaten, fordi z-aksen internt i programmet er orienteret i modsat retning af, hvordan den præsenteres for brugeren. Tallet vægstørrelse fastlægger opløsningen på de tre textures. Den er sat til 128, hvilket vil sige, at hvert texture består af 128*128 punkter. Benytter vi eksemplet med "Schlesinger, Arthur M." igen (med y sat til titel = "The cycles of American history" og z sat til udgivelsessted = "London" ), vil texturekoordinaterne kunne udregnes således:

x_værdi = "Schlesinger, Arthur M."
minimumværdi_x = "A"
maximalværdi_x = "Z"
=> talkode_x = 83,26
texturekoor_x = ((83,26- 65)/(90-65) * (128-2) +1 = 93

y_værdi = "The cycles of American history"
minimumværdi_y = "A"
maximalværdi_y = "Z"
=> talkode_y = 84,28
texturekoordinat_y = ((84,28 - 65)/(90 - 65) * (128-2) + 1 = 98

z_værdi = "London"
minimumværdi_z = "A"
maximalværdi_z = "Z"
=> talkode_z = 76,31
texturekoordinat_z = (128-1) - ((76,31 - 65)/(90 - 65) * (128-2) = 70

Når disse tre koordinater er beregnet, indsættes der et hvidt punkt i hvert af de tre vægarrays:

xy [texturekoordinat_x][texturekoordinat_y] = 0x7fff
xz [texturekoordinat_x][texturekoordinat_z] = 0x7fff
yz [texturekoordinat_y][texturekoordinat_z] = 0x7fff

0x7fff er den hexadecimale kode for hvid i en 16-bit Targa-fil.

Algoritme for generering af pointmode
{

	Gentag: for alle objekter i databasen
		Læs i tagfile
		Hvis: objektet skal med i rummet
		(værdien 7 i tagfile)
			Så:læs værdier for det pågældende
			objekt for de tre valgte variable
				Konverter værdier til alfabetiske talkoder
				Omregn til texturekoordinater
				Indsæt værdien 0x7fff (farven hvid)
				i hvert af de tre vægarrays
	Gentag slut

	Gem vægarrays som texturefiler (TGA-filer)
	Skab et fladt objekt på hver af de tre vægge
	Tildel textures til vægobjekterne
}

Til sidst, når alle punkter er indtegnet, gemmes de tre textures på harddisken og der oprettes tre objekter, som får tildelt de tre textures.

8.5.2 Swarmmode
I swarmmode vises rummets objekter som grafiske objekter svævende i rummet. De grafiske objekters udseende afhænger af de databaseobjekter, de repræsenterer: en bog ligner en bog, en artikel ligner en artikel, og en cd ligner en cd. Swarmmode genereres ved, at programmet for hvert objekt, der skal med i rummet, indlæser objektets værdier for de tre valgte variable, omregner disse værdier først til alfabetiske talkoder og derefter til rumkoordinater, hvorefter et objekt genereres på den pågældende position. De alfabetiske talkoder og rumkoordinater beregnes som tidligere beskrevet:

rumkoordinat_x = ((talkode_x-minimumværdi_x) / (maksimalværdi_x - minimumværdi_x) * rumlængde - rumstart) * kompressionsfaktor

rumkoordinat_y = ((talkode_y - minimumværdi_y) / (maksimumværdi_y - minimumværdi_y) * rumlængde - rumstart) * kompressionsfaktor

rumkoordinat_z = -((talkode_z - minimumværdi_z) / (maksimumværdi_z - minimumværdi_z) * rumlængde - rumstart) * kompressionsfaktor

Det er nødvendigt at invertere z-koordinaten, fordi z-aksen internt i programmet er orienteret i modsat retning af, hvordan den præsenteres for brugeren. Benytter vi det efterhånden velkendte eksempel, får vi følgende værdier (kompressionsfaktor = 0,5):

x_værdi = "Schlesinger, Arthur M."
minimumværdi_x = "A"
maksimalværdi_x = "Z"
=> talkode_x = 83,26
rumkoordinat_x = ((83,26 - 65)/(90 - 65) * 1000 - 500) * 0,5 = 115

y_værdi = "The cycles of American history"
minimumværdi_y = "A"
maksimalværdi_y = "Z"
=> talkode_y = 84,28
rumkoordinat_y = ((84,28 - 65)/(90 - 65) * 1000 - 500) * 0,5 = 136

z_værdi = "London"
minimumværdi_z = "A"
maksimalværdi_z = "Z"
=> talkode_z = 76,31
rumkoordinat_z = -((76,31 - 65)/(90 - 65) * 1000 - 500) * 0,5 = -24

I dette tilfælde vil der blive genereret et bogobjekt på position (115, 136, -24). At det skal være en bog og ikke en artikel eller cd afgøres ved at undersøge objektets base- og typeværdi. Er basen "05" er det artikel, er typen "c" er det en cd; alle andre værdier betragtes som bøger. I pseudokode ser genereringen af swarmmode således ud:

Algoritme for generering af swarmmode
{
Gentag: for alle objekter i databasen
	Læs i tagfile
	Hvis: objektet skal med i rummet (værdien 7 i tagfile)
		Så:
			Læs værdier for det pågældende objekt for de
			tre valgte variable
			Konverter værdier til alfabetiske talkoder
			Omregn til rumkoordinater
			Bestem type (artikel/bog/cd)
			Generér objekt på beregnet position
Gentag slut
}

8.5.3 Wallmode
I wallmode vises rummets objekter som grafiske objekter hængende på væggene. Hvert databaseobjekt er repræsenteret af tre grafiske objekter, et på hver af de tre vægge. Som i swarmmode afhænger objekternes udseende af det objekt, de repræsenterer (artikel, bog, cd). Wallmode genereres ved, at programmet for hvert objekt i rummet indlæser værdierne for de tre valgte variable fra databasen og beregner de alfabetiske talkoder og rumkoordinaterne. Denne del foregår fuldstændigt som ved genereringen af swarmmode. Derefter placeres for hvert databaseobjekt tre objekter med følgende koordinater:

(-495, rumkoordinat_y, rumkoordinat_z)
(rumkoordinat_x, -495, rumkoordinat_z)
(rumkoordinat_x, rumkoordinat_y, 495)

De -495 svarer til, at objektet hænger på væggen (eller rettere sagt, 5 fra væggen, idet objektet har en vis tykkelse). Grunden til, at værdien er 495 for z, er igen, at z-aksen internt er orienteret modsat af, hvordan den præsenteres. Som i swarmmode bestemmes objekternes udseende (artikel/bog/cd) udfra databaseobjektets værdier i type- og basefeltet. I pseudokode ser genereringen af wallmode således ud:

Algoritme for generering af wallmode
{
Gentag: for alle objekter i databasen
	Læs i tagfile
	Hvis: objektet skal med i rummet
	(værdien 7 i tagfile)
		Så:
			Læs værdier for det pågældende objekt 
			for de tre valgte variable
			Konverter værdier til alfabetiske talkoder
			Omregn til rumkoordinater
			Bestem type (artikel/bog/cd)
			Generer tre objekter på de beregnede positioner
	Gentag slut
}

8.5.4 Colormode
I colormode vises intensiteten af objekter i rummet som en 10*10 farvematrix på hver af de tre vægge. De tre matrixer genereres som textures, igen af hensyn til performance. Colormode genereres ved, for hvert objekt i rummet at indlæse værdierne for de tre valgte variable og beregne de alfabetiske talkoder og farvetexturekoordinater. Farvetexturekoordinaterne beregnes på følgende måde:

farvetexturekoordinat_x = (talkode_x - minimumværdi_x)/(maksimalværdi_x - minimumværdi_x) * 9,9

farvetexturekoordinat_y = (talkode_y - minimumværdi_y)/(maksimumværdi_y - minimumværdi_y) * 9,9

farvetexturekoordinat_z = 9,9 - (talkode_z - minimumværdi_z)/(maksimumværdi_z - minimumværdi_z) * 9,9

Disse formler giver som resultat et tal mellem 0.0 og 9.9. Ved afrunding skæres decimalerne væk, hvilket giver et heltal mellem 0 og 9, begge inklusive. I vores klassiske eksempel bliver værdierne som følger:

x_værdi = "Schlesinger, Arthur M."
minimumværdi_x = "A"
maksimalværdi_x = "Z"
=> talkode_x = 83,26
texturekoordinat_x = ((83,26 - 65)/(90 - 65) * 9,9 = 7

y_værdi = "The cycles of American history"
minimumværdi_y = "A"
maksimalværdi_y = "Z"
=> talkode_y = 84,28
texturekoordinat_y = ((84,28 - 65)/(90 - 65) * 9,9 = 7

z_værdi = "London"
minimumværdi_z = "A"
maksimalværdi_z = "Z"
=> talkode_z = 76,31
texturekoordinat_z = 9,9 - ((76,31 - 65)/(90 - 65) * 9,9 = 5

Når koordinaterne er beregnet, tælles følgende pladser i de tre farvearrays (arrays med 10*10 positioner) én op:

farvearray [farvetexturekoordinat_x, farvetexturekoordinat_y]++
farvearray [farvetexturekoordinat_x, farvetexturekoordinat_z]++
farvearray [farvetexturekoordinat_y, farvetexturekoordinat_z]++

Når alle objekterne er plottet ind i de tre farvearrays, omregnes indholdet af de tre arrays til nuancer af grøn. Dette gøres efter følgende skala:

0 objekter: sort (0x0000) - svarer til gennemsigtig
1 objekt: mørkeste grøn (0x0040)
2-29 objekter: lysere grøn afhængig af n ((n+2)/2*0x0040)
30+ objekter: lyseste grøn (0x03c0)

hvor n er antallet af objekter i det pågældende felt. Det skal lige bemærkes, at der anvendes en 16-bit RGB farveskala med fem bits til hver farve. Af disse fem bits benytter programmet kun de fire højeste for at give større kontrast mellem nuancerne.

Algoritme for generering af colormode
{
	Gentag: for alle objekter i databasen
		læs i tagfile
		Hvis: objektet skal med i rummet
		(værdien 7 i tagfile)
			Læs værdier for det pågældende objekt for de tre valgte variable
			Konverter værdier til alfabetiske talkoder
			Omregn til farvetexturekoordinater
			Læg én til i hvert af de tre farvearrays
	Gentag slut
	Omregn tal i farvearrays til nuancer af grøn
	Forstør farvearrays over i vægarrays
	Gem vægarrays som texturefiler (TGA-filer)
	Skab et fladt objekt på hver af de tre vægge
	Tildel textures til vægobjekterne
}

Efter at farverne er beregnet, forstørres farvearrayet over i vægarrayet, således at hvert punkt kommer til at fylde 10*10 punkter, hvilket giver et texture på 100*100 punkter. Dette texture gemmes på disken, og tre vægobjekter oprettes og tildeles dette texture. I teorien er det ikke nødvendigt at forstørre farvetexturet, for WTK forstørrer selv textures, så de passer til objektet, men desværre er der ofte visse problemer i kanterne af textures, hvilket kan få stor betydning for små textures, så for at være på den sikre side arbejder vi med relativt store textures.

8.5.5 Automode
Automode er en kombination af pointmode og wallmode. Den er velegnet, hvis man ikke på forhånd ved, hvor mange objekter en søgning vil resultere i. Inden programmet begynder at generere objekter, tæller det først, hvor objekter rummet kommer til at indeholde. Er antallet under 100, vælges wallmode, er det 100 eller derover vælges. pointmode. Automode er hensigtsmæssig, fordi programmet kun kan håndtere et begrænset antal grafiske objekter. Når man over denne grænse (over ca. 5000 objekter), hvad man godt kan presse wallmode til, går programmet ned. Selvom programmet kan klare så mange objekter, betyder det ikke, at det kører problemfrit op til denne grænse. Programmets hastighed afhænger af antallet af objekter, så flyvning i rummet vil gå meget langsomt ved stort objektantal. Til flyvning med en rimelig hastighed finder vi, at grænsen på 100 objekter (hvilket giver 300 grafiske objekter i wallmode) er passende.

8.6 Beskrivelse af hjælpeprogrammet
Udover selve Det virtuelle Bibliotek programmet har vi lavet et program, som konverterer en tekstfil til en databasefil og opretter indeksfiler. Dette program var nødvendigt, fordi vi fik udtrækket fra biblioteksdatabasen leveret som en tekstfil, der ikke var særlig anvendelig ifbm. Det virtuelle Bibliotek. Programmet er skrevet i C++ og kildeteksten findes i bilag G. Programmet består af en hovedfunktion, funktionerne konverter tekstfil og skab indeksfiler, samt en del små hjælpefunktioner, som ikke beskrives her.

Konverter tekstfil læser tekstfilen igennem og konverterer hver post til en post i databasefilen. Ved denne proces får hver post og hver attribut en fast længde, hvilket gør tilgang til posterne hurtigere. I pseudokode ser funktionen således ud:

Konvertér tekstfil
{
	gentag: indtil ikke flere poster
		læs linie fra tekstfil
		hvis: attributten indeholdt i linien
		skal med i databasen
			så: fjern overflødige tegn
		hvis: linien er tom
			så: skriv post i databasen og påbegynd ny post
	gentag slut
}

De enkelte poster i tekstfilen er adskilt af tomme linier, så når funktionen støder på en sådan, begynder den på en ny post.

Skab indeksfiler skaber en indeksfil for hver attribut (fem indeksfiler for attributten keywords, fordi hver post kan indeholde op til fem keywords). I pseudokode ser funktionen således ud:

Skab indeksfiler
{
	Gentag: indtil antal poster sorteret = 
	samlet antal poster
		Find mindste værdi ikke som ikke allerede
		er sorteret
		Skriv værdi og postens nummer i indeksfil
		marker at værdi er sorteret
	Gentag slut
}

Resultatet af et kald til skab indeksfiler er en sorteret indeksfil for en enkelt attribut (f.eks. titel). Sorteringen foregår som en lineær sortering, hvilket er en meget langsom, men til gengæld meget lidt hukommelseskrævende, proces.


9. Test

En traditionel datalogiopgave som vi kender den fra DØK-studiet lægger op til, at et program skal afprøves og dokumenteres ved en ekstern og en intern test. Vi har i denne opgave afgrænset os fra at lave en intern test, for der imod at bruge vores energi på at lave en tænke højt afprøvning - en usability test. Den eksterne test udføres på traditonel vis.

9.1 Ekstern test
I en traditionel test vil man teste programmet til dets grænser, for at sikre sig at der ikke er opstår nogle fejl, selv i ekstreme situationer. Dette kan deles op som korrekte og ukorrekte varianter, test af grænsetilfælde, stress-test og brugers afprøvning.

En korrekt variant er en lovlig indtastning i et felt, dog eks. efterfulgt af et mellemrum, som brugeren kan komme til at sætte ind. En ukorrekt variant kan f.eks. være et tal i et felt beregnet til bogstaver. Hvis der er angivet at man i et felt kan indtaste et tal mellem 0 og 100, så vil det være relevant at afprøve programmets reaktion på netop disse værdier, samt lige over (101) og lige under (-1). I en stress-test kan man eks. fjerne data filer der hører til programmet, og se om programmet kan redde sig ud af denne situation. Den sidstnævnte form er den såkaldte brugers afprøvning. Den tager typisk sit udgangspunkt i et eksempel fra brugervejledningen, og er til for at der også skal være eksempler på normale indtastninger. I vores situation ved vi godt at vores program er meget sårbart. Det accepterer ikke nogen form for fejlindtastninger, og går ned hvis de forekommer. Derfor vil det være irrelevant at gennemføre hovedparten af alle de ovennævnte testformer, med undtagelse af brugeren afprøvning, suppleret med nogle enkelte test af grænsetilfælde.

Testtilfælde til den eksterne test er at finde i bilag G. Skemaet er opbygget på følgende måde: I første kolonne beskrives der hvilken testsituation der tale om. Det kan være et valg af en kommando eller flyvning i rummet. Hvert testttilfælde har en kode, som er beskrevet i anden kolonne. I tredje kolonne beskrives hvilken reaktion der forventes når man udfører handlingen beskrevet i første kolonne. I sidste kolonne findes der en reference til hvor det helt nøjagtigt er beskrevet, hvad der skal tastes og hvor.

I bilag H findes et skema over testkørsler til den eksterne test. I første kolonne findes et referencenummer. Det svarer til referencenummeret i sidste kolonne i bilag G. I anden kolonne er der meget nøjagtigt beskrevet hvad man skal foretage sig, og hvad der skal indtastes. Nogle indtastninger tester mange testtilfælde, og hvilke der er tale om er nævnt i tredje kolonne. I fjerde kolonne findes der et nyt referencenummer, denne gang til en oversigt over uddata, for testene skal også dokumenteres. I femte kolonne er der plads til at gøre notater om, hvorvidt testens resultat var som forventet.

I bilag I findes testresultaterne fra den eksterne test. Vi har valgt at dokumentere testresultaterne på to måder: Den ene måde er baseret på de meddelelser som programmet giver i tekstvinduet medens programmet kører. I mange tilfælde var lettest at dokumentere resultatet af et testttilfælde ved at aflæse ændringerne i position og viewpoint, dvs. ved at taste "i" (som information). Alle disse testresultater er benævnt T1 til T3 i testskemaerne, og Tekst 1 til Tekst 13 i bilag I. I andre tilfælde var det bedst at dokumentere testresultatene ved at tage en udskrift af skærmen. I praksis blev udskrifterne dog gemt i en grafikfil. Dette gjorde vi i 35 tilfælde, og de er benævnt billede X1 til billede X35.

9.2 Tænke højt afprøvning
Tænke højt afprøvningen blev udført som en brugertest, hvor i alt fire brugere udførte en række øvelser og søgeopgaver i Det virtuelle Bibliotek. Brugerne blev bedt om at "tænke højt" under hele testen. Deres handlinger/reaktioner, udsagn og spørgsmål blev noteret undervejs.

Brugerne havde følgende profiler: En sociologi studerende (Ph.d.), der ofte anvender HHK biblioteket. Havde generelt edb-kendskab på brugerniveau. En bibliotekar (Bibl.), (dog ikke fra HKK biblioteket), som til daglig anvender bibliotekssystemer svarende til Hermes. Havde generelt edb-kendskab på brugerniveau. En matematik/økonomi studerende (VRx), der jævnligt anvender HHK biblioteket. Har en del kendskab til Virtual Reality brugergrænsefladen, samt generelt edb-kendskab over brugerniveau. En brugergrænseflade-ekspert (Bgfx), ligeledes med et vist forhåndskendskab til Virtual Reality, med et generelt edb-kendskab over brugerniveau.

Brugertesten var opdelt i to dele: Indledende øvelser i anvendelsen af systemet og søgeopgaver, som er de egentlige testopgaver. I bilag C er de indledende øvelser beskrevet. I bilag D findes opgaverne til tænke-højt afprøvningen. De rå resultaterne fra disse findes i bilag E, og i bilag F findes en oversigt over de problemer som blev fundet.

9.3 Generelle iagttagelser
Et helt basalt problem for alle testpersonerne var vanskeligheder ved at bevæge sig rundt i et 3D rum vha. en mus. Selv om musen i princippet tillader bevægelse og rotationer i alle retninger, brugte testpersonerne lang tid på at vænne sig til denne navigationsform. Ved de første forsøg havnede testpersonerne oftest med synsretningen ind mod vægge, gulv eller loft. Eller de kom til at vende synsretningen på hovedet osv. Faktisk nåede ingen at blive rigtig fortrolige med fri flyvning, men benyttede sig ofte af homefunktionen til at rydde op efter sig.

Et andet væsentligt problem var at holde rede på de valgte søgevariable og tilhørende afgrænsninger på de tre akser. Havde forsøgspersonen fokuseret på en væg, glemte vedkommende ofte den tredje søgevariabel, hvilket resulterede i "uforklarlige" resultater. Selvom forsøgspersonerne efterhånden blev opmærksomme på at valget af søgevariable og afgrænsninger på alle tre akser havde betydning for søgeresultater, så glemte de jævnligt at tage højde for den tredje søgevariabel. Bibl. foreslog problemet løst ved at have et lille statusvindue, der hele tiden viser aktuelt valg af søgevariable og afgræsninger på de tre akser. Problemet hænger muligvis sammen med at skærmopløsningen under afviklingen (pga. hastigheden) er for lav til at man kan se de mest fjerne afgrænsninger og variabelnavne.

Testpersonerne havde ofte svært ved at se sammenhængen mellem de tre vægge og udnytte, at de viste tre forskellige kombinationer af to variable. Dette medførte, at de tit kiggede på den forkerte væg og ikke fik den ønskede spredning af objekterne. Som VRx. udtalte, kræver det tid at vænne sig til at tænke i tre dimensioner.

Næsten alle testpersoner havde i starten problemer med at forstå og udnytte at objekters placering på vægge og i rummet kunne fortælle vigtige oplysninger om både enkeltstående objekter og grupper af objekter. Jf. opgave 2c hvor forsøgspersonerne blev bedt om at finde hvilke forlag, der har været toneangivende indenfor emneområdet "sociologiens historie". Forsøgspersonen skulle kombinere søgevariablene publisher og emneord. Resultatet var at bøger fra samme forlag hang i snorlige rækker. Men kun anvendte dette til at finde toneangivende forlag. Dog anvendte de alle denne teknik efterfølgende, efter at have fået forklaring.

Testpersonerne havde problemer med at huske keyboard kommandoer og spurgte ofte efter hjælp. Særlig indtastning af søgevariable og afgrænsninger fandt alle besværlig. Bibl. var irriteret over hvor ufleksibelt systemet var i forhold til traditionelle systemer. Bibl. fandt det unødvendigt at indtaste emneord to gange (fra og til værdi). Blev endvidere stærkt irriteret over at fejlindtastninger ikke kunne fortrydes og fik systemet til at gå ned. Flere af forsøgspersonerne forsøgte at vælge ny søgevariabel og afgrænsninger ved at klikke på disse. Ligesom andre nævnte det som væsentligt forbedringsforslag. Samme problem gjorde sig gældende med udvælgelsen med proben. Forsøgspersoner havde problemer med at styre proben vha. piletasterne og +/- tasterne. I den forbindelse udtrykte flere ønske om at kunne strække proben ud, således at den dækkede et større område.

Objekter, der lå oven i hinanden, var et tilbagevendende problem, som alle testpersonerne bemærkede. Mange forsøgte at løse problemet ved at explode det pågældende område, men dette var en besværlig løsning, især fordi der manglede en mulighed for at vende tilbage til den forrige søgning.

Ser man på anvendeligheden af de respektive visualiseringstilstande, så gav pointmode et udemærket overblik, men fordi specifikke oplysninger om enkeltpunkter ikke kunne fås, blev pointmode ofte erstattet af wallmode, der syntes at være den visualiseringstilstand de fleste forsøgspersoner foretrak. De fleste forsøgspersoner havde problemer med at overskue objekter i swarmmode. Dette var særligt et problem ved stor objekt tæthed. Endvidere havde alle testpersonerne meget vanskeligt ved i swarmmode at anvende proben til udvælgelse af objekter. Brugerne udtrykte problemet som en manglende fornemmelse for dybde i rummet. Det var således svært, hvis ikke umuligt, at se om et objekt var omkranset af proben. Colormode fungerede, og blev særligt anvendt i tilfælde hvor mange bøger var klumpet sammen omkring samme position.

Ved overgangen fra en opgave til den næste glemte mange af forsøgspersonerne at nulstille afgrænsningerne, så de igen fik alle objekter med. Den nuværende reset-funktion tog ikke alle objekter med og var derfor et dårligt udgangspunkt for en ny søgning. Alle testpersonerne fandt det uhensigtsmæssigt, at man ikke kunne gå tilbage til forrige søgning, især i forbindelse med udvalg med proben. Ofte valgte de at explode et område for at studere nærmere, fandt det så uinteressant og ville gerne tilbage igen.

9.4 Konklusion på test
Testen afslørede at Det virtuelle Bibliotek systemet kræver en betydelig tilvænningstid for brugere. Hver bruger fik 1½ time til at gennemføre de indledende øvelser og 1 time til at gennemføre de indledende øvelser. Alle brugere gennemførte minimum 80% af de indledende øvelser, men flere anførte at de gerne ville have haft mere tid til at gøre sig fortrolige med systemet. Af de i alt 7 egentlige søgeøvelser nåede Ph.d. at gennemføre to opgaver, Bgfx nåede 3, mens bibl. og VRx nåede fire opgaver. Vi mener at årsagen til den betydelige tilvænningstid primært skyldes følgende tre faktorer:

For det første indeholder det nuværende system en række uhensigtsmæssigheder, som gør det besværligt at bruge. Eksempelvis skal brugeren navigere i rummet vha. en mus, i stedet for med et mere intuitivt navigationsinstrument som f.eks. et joystick. Endvidere indeholder systemet et stort antal tastaturkommandoer, der er vanskelige at huske. Disse kunne i stedet være erstattet af mere intuitive museklik på akser, afgrænsninger m.v.

For det andet er det for brugeren nyt at skulle anvende en VR-brugergrænseflade, hvilket bl.a. indebærer at skulle tænke i tre dimensioner. Eksempelvis havde stort set alle brugere i starten vanskeligt ved at forholde sig til at objekters position i rummet, afslørede vigtige oplysninger om både enkeltstående objekter og grupper af objekter.

For det tredje er brugere i deres adfærd påvirket af at have arbejdet med traditionelle bibliotekssøgesystemer, hvilket gør at de tit forsøger at løse problemer i det nye system, med det gamle systems metoder. Jf. bibl., som i opgave 1a fik 311 poster indholdene emneordet "USA" vist og skulle finde de tre ældste bøger. Bibl. kunne have løst opgaven med de valgte afgrænsninger, men overså løsningen og valgte at afgrænse yderligere, med den begrundelse at "man i et normalt system ikke kan overskue 311 poster".

Førstnævnte problem, at systemet indeholder en række uhensigtsmæssigheder, kan et langt stykke hen ad vejen udbedres. Især brugerens kommunikation med systemet kan forbedres gevaldigt, med indførelse af bedre navigationsmuligheder og mere intuitive valg af søgevariable og afgrænsninger.

At VR brugergrænsefladen stiller krav til brugerens evne til at tænke tre dimensionalt kan man ikke laste systemet for. Det samme gælder at folk skal vænne sig til ikke at tænke i traditionelle systemers løsningsmetoder. Her må vi bare konstatere at det kræver tid at omstille sine tanker til det nye systems betingelser. Som VRx anførte, så kræver det tilvænning at tænke i tre dimensioner. Men at det kan lade sig gøre, så vi med samtlige forsøgspersoner. De første opgaver blev løst med nogen tøven og megen hjælp. Men når først brugerne havde fået forklaret de basale søgeteknikker, var de istand til at overføre dem på de efterfølgende opgaver, som blev løst klart hurtigere.


10. Konklusion

Brugertesten viste at brugerne havde væsentlige tilvænningsproblemer med det nye system. Primært tre faktorer var skyld i den lange tilvænningstid:

De mange uhensigtmæssigheder i det nye system var forårsaget af manglende økonomiske og tidsmæssige ressourcer. Disse uhensigtsmæssigheder kan dog med overkommelige midler overvindes, således at man får et system, der nærmer sig idealsystemet som det er skitseret i designafsnittet.

Men selv i det idealiserede system vil brugeren på grund af a) og b) kræve en vis tilvænningstid. For en bibliotekslåner er det således det højst tvivlsomt om vedkommende er interesseret i at bruge et par timer på at sætte sig ind i et så avanceret brugerinterface. Den typiske låner haster ind på biblioteket og forventer hurtigt og effektivt at kunne finde de ønskede oplysninger. Man kan derfor ikke forvente at den almindelige låner vil finde anvendelsesmulighed for et sådant system. Omvendt kunne man forestille sig at den professionelle bruger - bibliotekaren vil kunne drage fordel af systemet. Selvom bibliotekar forsøgspersonen var irriteret over mange uhensigtsmæssigheder ved systemet, kunne vedkommende dog alligevel se systemets anvendelighed til at skabe overblik over biblioteksdatabasen.

Vi må derfor konkludere, at systemet har begrænset anvendelighed som bibliotekssystem, da systemet, selv med påkrævede forbedringer, vil kræve en lang oplæringstid. Det er simpelthen for svært at illustrere den virkelige verden med noget virtuelt i situationer, hvor der kun er tale om perifert brug. Derimod kan man tænke sig andre anvendelsesområder, hvor man kan forvente at brugere vil være villige til at investere den nødvendige tid i et sådant system. Kendetegnende for datagrundlaget i disse systemer må være, at de skal være væsentlig mere objektorienterede end i det benyttede bibliotekssystem. Det skal også være mere simpelt, idet systemets force ligger i at give et overblik over en stor mængde informationer,, hvor det er let at identificere endog små afvigelser, og ikke til at foretage specifikke søgninger med.

Set i dette perspektiv kan man selvfølgelig ærgre sig over at vi ikke valgte et andet område med at anderledes datagrundlag, til at anskueliggøre VR brugergrænsefladens anvendelighed til at håndtere store og komplekse informationsmængder. Men selv om bibliotekslåneren muligvis ikke har behov for et sådan overblik som systemet kan tilbyde, så har systemet dog alligevel vist at VR giver brugere en unik mulighed for at håndtere store og komplekse informationsmængder.


11. Brugervejledning til Det virtuelle Bibliotek

11.1 Indledning til brug af Det virtuelle Bibliotek
Dette er en vejledning i brug af Det virtuelle Bibliotek. Det virtuelle Bibliotek kan afvikles under både Windows 3.11 og Windows NT 3.5, og henvender sig til brugere af begge versioner. I de tilfælde hvor der gælder specielle forhold for een af versionerne, vil dette blive anført. Det forudsættes at Det virtuelle Bibliotek allerede er installeret på computeren, samt at der er tilsluttet en Logitech 3D mus. Hvis Windows 3.11 benyttes skal der være installeret 32 bit extensions. Der kan endvidere være tilsluttet et joystick, men det er ikke påkrævet. Det virtuelle Bibliotek kan benyttes med en almindelig skærm. For optimal brug af Det virtuelle Bibliotek anbefales det at benytte et head-mounted desplay (HMD) med en høj opløsning.

Der er endnu en del fejl og mangler ved Det virtuelle Bibliotek, men den foreliggende version er også kun en eksperimentel prototype. Brugergrænsefladen adskiller sig væsentligt fra den endelige. I de tilfælde hvor uhensigtsmæssigheder i programmet gør, at programfejl eller lignende situationer kan opstå, vil det blive beskrevet hvorledes man kan undgå dette. Hvis denne vejledning følges til punkt og prikke, vil der ikke opstå fejl. Brugervejledningen er opdelt i følgende afsnit:

11.2 Start af programmet
11.3 Navigation
11.4 Visualiseringsmetode-valg
11.5 Søgning
11.6 Diverse funktioner

11.2 Start af programmet
Det forudsættes at Windows allerede er startet. Dobbeltklik på programgruppen WorldToolKit og dobbeltklik på ikonen Det virtuelle Bibliotek, for at starte programmet. Når Det virtuelle Bibliotek starter, vil følgende vise sig på skærmen, placeret ovenover hinanden.


Figur 14 Det virtuelle Bibliotek lige efter start

Det virtuelle Bibliotek arbejder altid med disse to vinduer. Det øverste er et grafisk vindue og viser informationsrummet, selve det virtuelle bibliotek. Det nederste er et tekstvindue, hvor meddelelser og informationer fra programmet bliver skrevet og hvor brugeren kan se sine indtastninger. Begge vinduer kan minimeres og maksimeres på normal vis. I det nedre vindue kan man endvidere se, hvad der tidligere er blevet skrevet, ved at benytte rullepanelet til højre i vinduet, eller ved at placere markøren i teksten, og trykke på page up. Allerede ved start af Det virtuelle Bibliotek blev der skrevet en masse i dette vindue. I afsnit 11.5 er der en komplet oversigt over alle funktioner og deres meddelelser er beskrevet.

Det virtuelle Bibliotek vil ved start foretage en automatisk søgning i databasen (på længere sigt er det tanken, at programmet ved opstart, i stedet for at foretage en standardsøgning skal huske seneste søgning fra seneste afvikling af programmet og starte op med denne). Der vil indtil søgningen er overstået ikke ske nogle ændringer i det øverste vindue. Under søgninger bliver der i det nederste vindue skrevet, hvor mange poster ud af alle dem som er resultatet af søgningen der er fundet frem. Hvis der eks. skrives "Found 161 of 188" betyder det, at der nu er fundet 161 poster ud af 188 i alt. Efter endt søgning dannes informationsrummet i det øverste vindue. Det kan godt tage lidt tid. Det virtuelle Bibliotek er nu klart til brug.


Figur 15: Objekter omkranset af proben

Midt i rummet er der placeret en stor transparent kube, eller gennemsigtig terning om man vil. Denne betegnes proben, og kan bevæges rundt i rummet vha. 3D-musen eller piletasterne og +/- knapperne. Proben kaster en slags skygger ind på tre af væggene. Skyggerne svarer størrelsesmæssigt til proben. Objekter som befinder sig inden for probens rum, kan markeres på en speciel måde. Det kaldes for 'highlightning'.


Figur 16: Probe med highlightede objekter

Væggene betegnes både med et nummer og et navn. Væg 1 til venstre betegnes 'xy', væg 2 til højre 'yz' og væg 3 i gulvet 'zx'. Tilsammen udgør deres tre akser (x, y og z) et tredimensionelt koordinatsystem. På hver af de tre vægge er der to akser (en for hvert koordinat) med de start- og slutværdier, der tilhører akserne.


Figur 17: Bog med lang titel og tekst

De objekter der er placeret i rummet eller på væggene, kan vises som bøger, artikler eller cd'er. Dette skal ses som et udtryk for hvilket medie objekterne findes på i virkeligheden. Hvis objekterne vises på væggen, kan dette enten gøres som beskrevet ovenfor, eller hvis der er mange objekter som skal vises, som små punkter. Selv med den største forhåndenværende pc skal der ikke meget til for at Det virtuelle Bibliotek kan blive overbelastet. Det kan godt tage lidt tid at hente alle objekter ind i rummet, og hvis der er for mange objekter, så vil det gå langsomt at bevæge sig rundt i rummet.


Figur 18: Cd med kort titel

Derfor anbefales det at man prøver at holde sig fra visualiseringer med over 800 polygoner. I kapitel 5 vises det hvordan man kan aflæse antallet af polygoner.


Figur 19: Artikel med lang titel og tekst

11.3 Navigation
Det er ikke muligt at bevæge sig uden for Det virtuelle Biblioteks seks vægge. Man skal forestille sig, at man befinder sig på et slags flyvende tæppe, med synsfeltet vendt i flyveretningen. De normale love om tyngde er ophævet, og man kan således godt hænge på hovedet uden at det gør noget. Grundliggende kan man bevæge sig rundt i informationsrummet på to forskellige måder:

Derudover findes der en række funktioner som gør, at man automatisk bliver placeret i rummet på forskellig vis. En oversigt over disse funktioner findes i afsnit 5.

Fri flyvning
Der er forskel på, om der benyttes en almindelig mus eller et joystick til fri flyvning. Hvis der benyttes et joystick (kun muligt under Windows 3.11, ikke Windows NT), kan man opnå følgende handlinger vha. bevægelser med joysticket:

Fri flyvning med joystick - kun til rådighed under Windows 3.11
Handling Bevægelse med joystick
Flyvning frem/tilbage Joystick bevæges henholdsvis frem og tilbage
Flyvning venstre/højre Joystick bevæges henholdsvis mod venstre og højre, samtidig med at øverste joystickknap holdes nedtrykket
Fri flyvning op/ned Joystick bevæges henholdsvis frem og tilbage, samtidig med at øverste joystickknap holdes nedtrykket
Drejning fremover/bagover (drejning om x-aksen) Joystick bevæges henholdsvis frem og tilbage, samtidig med at forreste joystickknap holdes nedtrykket
Drejning venstre/højre (drejning om y-aksen) Joystick bevæges henholdsvis mod venstre eller højre
Drejning sidelæns (drejning om z-aksen) Joystick bevæges henholdsvis mod venstre eller højre, samtidig med at forreste joystickknap holdes nedtrykket

Hvis der benyttes en mus, i stedet for et joystick, placeres musemarkøren på bestemte steder på skærmen, hvorefter musens knapper styrer bevægelsen som beskrevet nedenfor:

Fri flyvning med mus
Handling Placering af musemarkøren
Flyvning frem/tilbage Musemarkøren placeres i den øverste halvdel af skærmen for frem, og i den nederste for tilbage. Jo længere oppe/nede pegeren placeres (i forhold til midten), des hurtigere vil bevægelsen ske. Bevægelsen sker når venstre museknap trykkes ned, og så længe den holdes nedtrykket.
Flyvning op/ned Musemarkøren placeres i den øverste halvdel af skærmen for frem, og i den nederste for tilbage. Jo længere oppe/nede pegeren placeres (i forhold til midten), des hurtigere vil bevægelsen ske. Bevægelsen sker når venstre museknap trykkes ned, og så længe den holdes nedtrykket.
Drejning venstre/højre (drejning om y-aksen) Som flyvning frem/tilbage, blot placeres musemarkøren i venstre/højre side af skærmen
Drejning fremover/bagover (drejning om x-aksen) Musemarkøren placeres i den nederste/nederste halvdel af skærmen, hvorefter både venstre og højre museknap holdes nede.
Drejning sidelæns (drejning om z-aksen) Musemarkøren placeres i et af de fire hjørner, hvorefter både højre og venstre museknap holdes nede.

Flyvning mod valgt objekt (Point-of-interest flight)
Dette er et supplement til fri flyvning, og anvendes til hurtigt og præcist at bevæge sig hen til et bestemt objekt. Denne navigationsform kan kun benyttes vha. en almindelig mus. Musens markør placeres på det objekt man ønsker at flyve til, og der klikkes på objektet med den midterste museknap. Flyvningen sker automatisk, idet ruten beregnes af programmet. Slutposition for flyveturen vil være umiddelbart foran forsiden på det valgte objekt. Synsfeltets orientering vil løbende blive korrigeret under flyveturen, således at forsiden ved ankomst udfylder hele synsfeltet.

Bemærk, at der stadig er nogle uløste uhensigtsmæssigheder ved funktionen. Bla. virker funktionen ikke på objekter, der står umiddelbart bagved proben. Ej heller tages der forbehold for om objekter som står umiddelbart foran det valgte objekt, 'skygger' for udsigten. Endelig er det også svært, hvis ikke umuligt, at vælge mellem objekter, der ligger oven i hinanden.


Figur 20: Pointmode

11.4 Valg af visualiseringstilstand
Det virtuelle Bibliotek har fem visualiseringstilstande, forskellige måder, hvorpå biblioteksdatabasens indhold visualiseres: Pointmode, wallmode, swarmmode, colormode og automode.

Pointmode viser søgeresultater som punkter på tre af rummets vægge. Ikke hele væggens flade benyttes til at vise resultatet. Fra start af kun de midterste 50%, men det kan indstilles efter behov. Pointmode er velegnet til at give et overblik over store mængder information, f.eks. resultatet af en søgning, som giver mere end 100 objekter. Samtidig er pointmode den mindst beregningstunge visualiseringsmetode, både i startberegningerne og i afviklingen. Dvs. at det er i denne tilstand, bevægelse rundt i rummet går hurtigst.


Figur 21: Colormode

Colormode ligner pointmode, men viser ikke de enkelte objekter. I stedet inddeles hver væg i et antal firkanter, hvor koncentrationen af objekter i den enkelte firkant afgør hvilken farve firkanten skal antage. Hvis koncentrationen er lav, vil firkanten være mørkegrøn, hvis koncentrationen er høj, vil firkanten være lysegrøn.

Swarmmode viser søgeresultater som objekter (bøger, artikler eller cd'er) hængende som en sværm midt i rummet. Ikke hele rummet fyldes ud af sværmen, men kun en del der størrelsesmæssigt svarer til akserne på væggene i pointmode. Der vil således være et mellemrum mellem væggene og sværmen. Dette mellemrum gør det muligt at flyve rundt og betragte objektsværmen udefra. swarmmode er langt mere beregningstungt end pointmode, og anbefales derfor kun til mindre søgninger, dvs. søgninger der resulterer i 100 objekter eller mindre.


Figur 22: Swarmmode

Wallmode viser søgeresultater som objekter (bøger, artikler eller cd'er) på tre af rummets vægge. Hvor swarmmode visualiserer objekterne midt i rummet, viser wallmode de samme objekter afbildet tre gange, en på hver væg. Det betyder, at wallmode er omkring tre gange tungere at afvikle end swarmmode, hvilket igen betyder, at det kun kan anbefales til visualisering af endnu mindre søgninger end swarmmode, dvs. søgninger der resulterer i 50 objekter eller færre.


Figur 23: Wallmode

Automode. Ofte kan det være vanskeligt at forudsige, hvor mange objekter en vilkårlig søgning vil resultere i, og dermed hvilken visualiseringstilstand, der er den optimale. Man bør derfor altid starte søgninger i pointmode, og kun skifte tilstand hvis antallet af fundne objekter kommer under 100. Hvis man ønsker, at programmet selv vælger den optimale visualiseringstilstand, vælges automode. Automode vil automatisk vælge pointmode hvis det fundne antal objekter er over 100. Er antallet af fundne objekter 100 eller derunder, vælges swarmmode. Visualiseringstilstanden ved programstart er automode som standard.

Skift mellem tilstande
Valg mellem tilstande, og generelt al kommunikation mellem Det virtuelle Bibliotek og brugeren, foregår vha. tastatur-input. Hvorledes man står placeret i rummet, når man skifter tilstand eller giver en kommando, er irrelevant, man skal blot sørge for at det øverste vindue (dvs. grafikvinduet) er aktivt. Efter tryk på 'm' (for 'mode') på tastatur er det muligt at angive visualiseringstilstand der en dialogboks der bliver placeret midt på skærmen. Hvis den skygger for hvad der står et af vinduerne, kan den flyttes rundt efter behov.


Figur: Dialogboks (tom)
Der er nu fem valgmuligheder:

Indtast det ønskede bogstav, og tryk på 'retur'. Programmet vil nu genberegne rummet. Hvor langt den er kommet med søgningen vises i det nederste vindue, og til sidst gentegnes rummet i det øverste vindue. Undervejs kan der ikke flyves rundt i rummet, eller foretages andre handlinger.

Bemærk!! Programmet kontrollerer ikke det indtastede. En indtastning ud over det ovenfor nævnte vil sandsynligvis medføre programnedbrud!

11.5 Søgning
Søgninger i biblioteksdatabasen foregår gennem en kombination af valg af a) søgevariable og indtastning af afgrænsninger og b) udvælgelse af en delmængde af rummets objekter vha. proben. Valg af søgevariable og indtastning af afgrænsninger foregår gennem tastaturinput, på samme måde som skift mellem tilstande. Først indtastes der et bogstav:

Når der er blevet indtastet en af de ovennævnte muligheder, vises der igen en dialogboks. I det nederste tekstvindue kan man læse hvad det er man skal indtaste. Først skal der indtastes hvilken variabel der skal knyttes til x-aksen. Dernæst minimum- og maksimum-værdier.

Eksempel på indtastning: Først tastes 'x' for at vælge x-aksen. Så vises dialogboksen på skærmen, hvor variablens nummer skal indtastes. Det kan f.eks. være '6', efterfulgt af 'retur'. Nedenfor findes en liste over mulige variabelnumre. Herefter fremkommer en ny dialogboks hvori minimumværdi for søgningen skal angives. Det kan f.eks. være '1985', efterfulgt af 'retur'. Igen fremkommer en dialogboks, hvor maksimumværdi skal indtastes. Det kan f.eks. være '1988', efterfulgt af 'retur'.

Liste over mulige søgevariable
Nr. Variabelnavn Forklaring
0 ID Internt database id på objekt
1 Author Forfatternavn
2 Title Titlen på bogen/artiklen/cd´en
3 Subtitle Eventuel undertitel
4 Published_in Eventuel titel på udgivelsessted
5 Publisher Navn på udgiver
6 Year Årstal for udgivelsen
7 Size Antal sider
8 Materialtype Mulige værdier: Trykt tekst, mikrokort, cd-rom/disketter, AV-materialer. Angives som en talværdi XX
9 Base Database som objekt stammer fra. Mulige værdier: Emneordsbase, Monografibase, periodikabase, artikelbase, årsberetningsbase, AV-base, bibliografibase. Angives som en talværdi XX
10 Keywords Emneord

Bemærk!!: Der er ingen kontrol af validiteten af indtastede variabelnumre og afgrænsninger. Fejlindtastninger vil sandsynligvis medføre programnedbrud!

Afgrænsning af søgeområdet vha. proben
Udover ovennævnte søgemetoder kan en delmængde af rummets objekter udvælges vha. proben, således at de kan undersøges på nærmere hold. I swarmmode kan de objekter, der befinder sig indenfor probens grænser til ethvert tidspunkt "eksploderes", så de udfylder hele rummet. I praksis betyder det, at rummet gentegnes med nye afgrænsninger på akserne, der svarer til det område i rummet, der var markeret med proben. For at eksplodere et markeret område, tast da 'e' (for eksplode).

For kunne eksplodere et område i pointmode og wallmode, (der jo viser objekter på væggene), vil programmet spørge hvilken af de tre skygger, der skal eksploderes. Der kommer nu en dialogboks op midt på skærmen, hvor der kan indtastes nummeret på væggen, '1' (xy), '2' (yz) eller '3' (xz). Dette efterfølges af 'retur'. Hvis der er tilsluttet en 3D mus til systemet, vil proben blive bevæget vha. denne. Når en af knapperne på siden er trykket ind, bevæges proben i forhold til 3D musens position. For at 'explode' et område, skal der klikkes på venstre museknap på 3D-musen.

11.6 Beskrivelse af samtlige funktioner
Til næsten hvert eneste bogstav på tastaturet er der tilknyttet en funktion. De kan alle aktiveres når det øverste vindue er aktivt. Det er ikke ligegyldigt om man taster store eller små bogstaver. Funktionerne bliver gennemgået i alfabetisk rækkefølge, i forhold til hvilken tast på tastaturet de er tilknyttet. Til sidst findes en oversigt over tastetryk/funktioner.

Wall position. Bringer udsynet hen til en position umiddelbart foran de tre vægge, således at alle objekter på væggen er inden for synsfeltet. Vælg: '1' for væg xy, '2' for væg zy og '3' for væg xz.

Acidtrip. En temmelig ligegyldig lille funktion. Den opstod egentlig som en fejl, og er bibeholdt i systemet fordi den er sjov. Når den er valgt, vil alle flyvninger i rummet, som ikke foretages vha. joystick eller klik med musen, får forvredet deres bane i en uforudsigelig grad. Vægge bliver strukket og det ser ud som om at man bliver hevet ud af rummet for straks at blive smidt tilbage igen. Meget morsom. Slå til/fra: 'a'.

Rhymes. Endnu er fiks lille funktion fra programmørernes side. Når den er slået til vil programmet komme med et lille rim som svar på udvalgte tastaturtryk! Hvilke tastaturtryk det drejer sig om, er op til brugeren at afprøve. Noget mere morsom end den ovenstående funktion. Slå til/fra: 'b'. 0

Change all variables. Hvis man ønsker at ændre alle tre variable på een gang, kan det betale sig at benytte denne funktion i stedet for at ændre variablene hver for sig. Den gør, at man i rækkefølgen x, y og z bliver bedt om at indtaste variabelnummer, maksimum- og minimumafgrænsning for hver koordinat i en dialogboks. Vælg: 'c'

Distant titles. Gør at man i tekstvinduet får vist alle informationer om det objekt man klikker på. Dette kan gøres uden at man er nødt til at flyve hen til objektet. Det er heller ikke muligt når denne funktion er slået til, idet den samme museknap bruges til at klikke når man peger på et objekt med musemarkøren. Slå til/fra 'd'.

Vælg objekt. Placér musemarkøren på det ønskede objekt, og tryk på midterste museknap.

Explode probe area. Hvis der er et område i rummet som ønskes forstørres, så skal man vælge Explode. Herefter vil et nyt rum blive dannet, hvori kun de objekter som befandt sig inde i proben bliver vist. Dette kan være nyttigt i en søgeproces, hvor den første søgning frembringer et meget stort antal objekter, og man ønsker at sortere nogle fra. Hvis der er valgt pointmode eller wallmode vil man blive spurgt hvilken af væggene der skal Explode's. Vælg: 'e'

Change compression factor. Som udgangspunkt er objekter i rummet komprimeret til 50%. Det betyder, at sværmen kun fylder 1/27 af rummet. Det samme gør sig gældende for væggene, hvor koordinatsættet ligeledes er komprimeret til 50% på hver af de fire sider. Komprimeringsfaktoren kan ændres. Det anbefales ikke at benytte faktorer over 70% og under 40%, da rummet vil blive forvredet for meget. Vælg: 'f'. Indtast derefter komprimeringsfaktor (1-100) i dialogboksen, efterfulgt af 'retur'.

Guided tour. En lille servicefunktion. Her bliver man gratis fløjet en lille tur rundt i rummet, så man kan danne sig et lille overblik over, hvad det er man har begivet sig ud i. Virker ikke helt efter hensigten, hvilket skyldes at WorldToolKit, som programmet er udviklet i, ikke helt kan finde ud af at interpolere rigtigt mellem de valgte punkter på flyveturen. Vælg: 'g'.

Home position. En meget vigtig funktion. Den vil bringe ens position og udsyn tilbage til den position man tog sit udgangspunkt. Dette kan ske uanset hvor og hvordan i rummet, man befinder sig, og hvordan man tidligere har fløjet rundt i rummet. Flyveruten beregnes automatisk, og undervejs korrigeres synsfeltets automatisk, på samme måde som ved flyvning mod et valgt objekt. Vælg: 'h'.

Info. Dette giver en række informationer som umiddelbart kun er forståeligt for viderekomne. For det første, så bliver den aktuelle position og orientering angivet i tekstvinduet. Dette angives som en række reelle tal med et stor antal betydende cifre. Tallene vil ikke sige en udenforstående noget. Antallet af polygoner i rummet samt det maksimale antal frames (skærmbilleder som er blevet tegnet på skærmen) i sekundet vises også. Vælg: 'i'.

Highlightning. Når proben omkranser et objekt kan det godt være svært at se, hvis man befinder sig lidt på afstand. Derfor kan man slå en særlig markering af objekterne til, således at de lyser hvidt hvis de befinder sig inden for probens grænser. Slå til/fra 'l'.

Mode. Dette er blevet gennemgået i et tidligere afsnit, og bruges til at vælge mellem de 5 visualiseringstilstande. Vælg: 'm'. Derefter fremkommer der en dialogboks, hvor der kan tastes 's' for swarmmode, 'p' for pointmode, 'w' for wallmode, 'c' for colormode og 'a' for automode i en dialogboks, efterfulgt af 'retur'.

Info on object in textwindow. Hvis man klikker på et objekt med den midterste museknap bliver man automatisk fløjet hen til objektet. Men hvis klikker een gang til på objektet, bliver informationerne om objektet skrevet i tekstvinduet. Hvis denne funktion er slået fra, vil informationerne i stedet blive indlæst, så de står direkte på bogen. Det kan godt tage noget tid. Slå fra/til: 'n'.

Thin objects. Dette er en funktion som kan sætte farten gevaldigt op. Antallet af polygoner i rummet beskæres i heldigste fald til omkring 17%! Det gøres ved at lave alle objekter i rummet om, således at de kun består af en for- og en bagside. Bøger ser selvfølgelig ikke ud som bøger længere, idet de mister deres tykkelse. Slå til/fra: 'o'.

Probe. Det er ikke altid lige spændende at have proben med i rummet. Den kan skygge for objekter, eller gøre det vanskeligt at se dem. Men så kan man slå den fra. Slå fra/til: 'p'.

Quit. Afslutter programmet. Vælg: 'q'.

Reset variables. Denne funktion bringer ikke systemet tilbage til før man lavede om på variable eller afgrænsninger, som man måske skulle tro. I stedet indlæses År, Forfatter og Udgiver som de tre variable, og årstallet sættes til 1975 - 1985. Det giver omkring 1125 objekter, så lad være med at gøre dette i swarm- eller wallmode. Vælg: 'r'.

Short objecttitles. At have informationer på objekterne (bøger og artikler) er noget som er meget ressourcekrævende. Som udgangspunkt er der ingen informationer på objekterne. Denne funktion gør, at en forkortet version af objekternes informationer bliver skrevet på dem. Det kan godt tage lang tid alligevel. Slå til/fra: 's'.

Long objecttitles. Som beskrevet ovenfor, så er det at have informationer på objekterne (bøger og artikler) meget ressourcekrævende. Denne funktion vil slå alle detaljerne til på objekterne. Advarsel: Det kan godt tage meget lang tid at generere alle objekterne. Det anbefales at undlade at slå denne funktion til hvis der er mere end 15-20 objekter på skærmen. Slå til/fra: 't'.

Objecttextures. Denne funktion kan rent faktisk slå samtlige bitmaps på objekterne fra (med undtagelse af cd´er. Så ligner en bog selvfølgelig ikke en bog længere, men programmet bliver væsentligt hurtigere. Slå til/fra: 'u'.

Change variables. Denne funktion er også blevet gennemgået tidligere. Bruges til at ændre variablen som benyttes på henholdsvis x-, y- og z-aksen, samt afgrænsninger herfor. Vælg: 'x', 'y' eller 'z'. Derefter indtastes henholdsvis maksimum- og minimumværdien for variablen i dialogboksen. Efterfølges af 'retur' efter hver indtastning.

Kontrol af proben
Hvis der ikke er tilsluttet en 3D-mus til systemet, kan problem også bevæges vha. piletasterne. Dette vil bevæge proben i det vandrette plan. Til at bevæge proben op/ned, benyttes + og minus. '-' bevæger proben op, og '+' bevæger proben ned.

Skema over kommandoer og deres
betydning i Det virtuelle Bibliotek
Tast Betydning Tast Betydning
1 Wall 1. position (XY) m Mode (visualization)
2 Wall 2. position (XZ) n Info on object in textwindow
3 Wall 3. position (YZ) o Thin objects on/off
a Acidtrip p Probe on/off
b Rhymes on/off q Quit
c Change all variables r Reset variable
d Distand titles s Short objecttitles on/off
e Explode (probe-area) r Long objedttitles on/off
f Change compression factor t Objecttextures on/off
g Guided tour v **** ubrugt ****
h Home position w **** ubrugt ****
i Info x Change X-variable
j **** ubrugt **** y Change Y-variable
k **** ubrugt **** z Change Z-variable
l Highlightning on/off


12. Praktiske erfaringer

Dette afsnit omhandler vores erfaringer med indkøb af hardware og software, brug af disse i kombination, programmering af et VR-system samt fremskaffelse af litteratur - bøger og artikler.

12.1 Hardwareindkøb
I sin tid havde vi en ide, om at et VR-system var noget med en handske og en 'maske'. Den ide havde dannet sig ud fra en forestilling om, at det var det som 'folk' tænkte mest på når de tænkte på VR. Samtidig havde vi selv en brændende lyst til at afprøve nogle af de ting som vi havde set på film og i massemedierne, men som var forbeholdt de få. Vi gik således på jagt efter en billig handske og et HMD.

Vores primære kilde til leverandører af VR-udstyr har været det amerikanske blad "CyberEdge Journal". Det udkommer 6 gange om året, og man kan abonnere på det for ca. 900 kr./år. Det indeholder artikler om produktlanceringer, konferencer ol., og har selvfølgelig en del reklamer.

Der var kun to leverandører af low-end (pc-baserede) VR-systemer som annoncerede, sammem med nogle af de store (som f.eks. engelske dVISION, som vi godt vidste leverede systemer i den dyre ende). Vi kontaktede de to leverandører, VREAM og Sense8, og bad dem om at sende noget materiale.

På daværende tidspunkt vidste vi ikke at der faktiske ikke findes flere producenter af low-end VR-udviklingssoftware. En tredje produkt, Cyberspace Development Kit fra amerikanske AutoDesk, fandt vi meget tidligt ud af at holde os fra, idet den første version ikke var særligt vellykket, og den kommende version, som var planlagt til lancering i efteråret '94, var meget forsinket (er p.t. ikke udkommet endnu).

På samme tid var vi på jagt efter bøger om VR. Vi fik tidligt fat på bogen "Garage VR" af Linda Jacobsen. Som titlen hentyder til, så handler bogen om hvordan man kan lave VR-systemer i sin egen garage (en dansker ville nok gå ned i kælderen for at gøre det!). Bogen var en guldgrube for dem som ikke er bange for at hente loddekolben frem og kortslutte et par baner på et printkort, så man kan koble et par Sega shutterglasses (briller der i princippet virker som en gasplasma-skærm, blot indbygget i et par briller) til sin seriel-port. Der var også opskrifter på, hvordan man byggede sit eget HMD ud af et par 2-tommer LCD skærme fra et Sony hånd-tv. Der var mange flere gode forslag, men vi tændte ikke lige på at skulle kode vores egne drivere i assembler osv.

Når man ser VR-systemer i medierne, er det tit, at den hardware, som benyttes, ikke lige er den sidste nye. Det skyldes selvfølgelig, at det selv for multinationale selskaber kan tage flere år at udvikle VR-systemer, idet de som så mange andre må eksperimentere sig frem. En af de mest sete platforme består af en VPL DataGlove (handske) og en Virtual Research Flight Helmet (HMD). Det er hardware, som var hot for 2-3 år siden. Vi havde en begrundet forestilling om, at denne hardware ville være alt for dyr for os, og desuden havde vi læst i pensum at VPL var gået konkurs.

Men så var det at vi så, at der i "Garage VR" var et helt kapitel helliget til beskrivelsen en handske. Handsken, en Mattel PowerGlove, var egentlig et stykke legetøj, som kunne kobles til en Sega spillekonsol. Den var blevet kåret til toy-of-the-year i USA i 1990 og 1991, og var blevet solgt i over 1 million eksemplarer. Desværre var der aldrig kommet nogle spil specielt designet til den, og at spille almindelige spil med den gjorde faktisk spillene sværere. Desuden snærede handsken ved længere tids brug (den havde kostet 99$ i udsalgspris). Produktionen blev brat nedlagt i 1992, og siden er der ikke kommet et lignende produkt i handelen.

Men i "Garage VR" er der opgivet en række adresser på forhandlere, som burde ligge inde med et restlager. Vi kontaktede alle dem, som stadig eksisterede, men kun i et enkelt tilfælde gav det bonus. I det tilfælde var der tale om brugte PowerGloves, der var blevet restaureret og udbygget med controller, der kunne sluttet direkte på en parallelport. Prisen for dette var 600$. WTK understøtter rent faktisk brugen af en PowerGlove, men alt i alt gav den et indtryk af at være lidt for legetøjsagtig til, at man rigtig kunne forvente noget af den.

Vores søgen efter hardware var betinget af, at det skulle være kompatibelt med det softwareprodukt vi endte op med. Vi var i lang tid usikre på hvilke produkter der kunne benyttes sammen, indtil vi modtog materialet fra VREAM, hvor der fulgte en hardwarekompabilitetsliste med! Dette var en guldgrube af information, idet vi ikke havde hørt om hovedparten af produkterne tidligere. Især var der listet en række producenter af HMD'er, hvilket vi havde manglet indtil da.

Vi ringede rundt til samtlige producenter og fik dem til at sende noget materiale om deres produkter. Det drejede sig om producenter af lydkort (hvilket ikke bragte os noget nyt, idet vi var godt bekendt med produkter så som Creatives SoundBlasterkort og Gravis Ultrasound), positioneringsdevices (fodpedaler, avancerede trackballs og mus), tracking devices (som f.eks. den 3D mus og 3D tracker vi endte op med, samt en række andre elektromagnetiske trackere). Så var der en række HMD'er, samt nogle andre display devices (f.eks. shutterglasses). Samtidig blev vi ved med at finde produktoplysninger i diverse blade, og få informationsmateriale tilsendt.

Vi havde efterhånden opbygget et solidt kendskab til de produkter der var på markedet, og vores ideer om en hardwareplatform ændrede sig noget. Vi opgav at benytte en handske, og gik i stedet efter at benytte en anden positionerings eller tracking device, som f.eks. en 3D mus eller SpaceController (en kæmpemæssig trackball, med en kugle større end en billardkugle).

Vi fandt ud af, at det ikke var nok at have eks. en 3D mus og et HMD, men der skulle også noget til for at kunne registrere hovedets bevægelser, således at rummet kunne blive ændret herudfra. På 3D musen og for den sags skyld PowerGlove gøres dette ved hjælp af en ultrasonisk tracker. Den består af tre bittesmå højtalere og tre tilsvarende mikrofoner. Ultrasonisk lyd er ikke hørbart for mennesker, og for den sags skyld heller ikke en hund, der jo har en bedre hørelse. Positionsændringerne registreres ved at måle forsinkelserne i lydbølgernes udbredelser, og så sammenligne resultaterne, for kunne gøre det i tre dimensioner.

En anden måde at gøre dette på er at benytte en elektromagnetisk tracker. Det lyder måske voldsomt, men der er tale om et absolut svagt magnetfelt. Ideen er den samme som med ultrasonisk lyd, blot er den elektromagnetiske løsning betydelig mere stabil og dynamisk, idet den fungerer i alle retninger, modsat en ultrasonisk tracker, der kun virker i en vinkel på omkring 80o på hver side af mikrofonerne. Endvidere er en elektromagnetisk tracker hurtigere til at opdatere positioner, og heller ikke følsom overfor for legemer der måtte komme imellem emitter og transmitter.

Den eneste bagdel er, at en almindelig elektromagnetisk tracker typisk koster omkring 2500$, hvilket i vores sammenhæng er temmelig dyrt. Men i professionel sammenhæng er den absolut at foretrække. Man kan meget let koble et stor antal trackere sammen, og placere emitterne på forskellige steder på kroppen. Det er en meget udbredt metode i filmindustrien, hvor man skal digitalisere kropsbevægelser.

Valget faldt til sidst på en løsning fra Logitech, som bestod af en ultrasonisk mus og en tilsvarende tracker. Fordelen er, at deres modtageenheder kan kobles sammen, og vi mente, at det så ville være lettere rent programmeringsmæssigt at kommunikere med dem.

Vores søgen efter HMD'er begyndte på et tidspunkt, hvor det, der var fremme, stadig var lidt dyrt, og hvor alle i branchen kom med forhåbninger om, at der ca. om et halvt års tid kom nogle nye produkter, der ville være noget billigere. Hardware-kompabilitetslisten fra VREAM gav os en god indgangsvinkel, og vi fik tilsendt noget godt informationsmateriale. De klart bedste low-end HMD'er kom fra Virtual Research, en af de store på området. Deres produkter, EyeGen 3 og 4 var nogle af de mest benytte HMD'er på VR tracket på SIGGRAPH '94, ud af 14 benyttede modeller. Forskellen mellem dem ligger i, at den ene benytter katoderør til at danne billedet, den anden lcd'er. De har begge en meget flot opløsning, og er ultralette. Bagdelen er, at de begge koster 9800$!

Vi så på et utal af andre HMD, og i alle prisgrupper. Valget af HMD måtte i sidste ende blive et kompromis mellem prisen og billedets opløsning (antal pixels). Vi valgte den mindste model fra et firma der hedder Virtual Research. De laver HMD'er og komplette VR-systemer i mange størrelser, hvoraf de største HMD'er koster over 50.000$ Men så får man også god grafik, op til 1280 X 1024 pixels (det er RET meget). Den valgte model hed P1, kostede 3000$ (- 10% studierabat!), og havde en opløsning på 479 x 234 pixels). Billederne dannes af LCD-displays. HMD'et kræver et almindeligt RGB signal, men det skal være i NTSC-format. Derfor må man også have en enhed der kan konvertere grafikkortets VGA output til NTSC (omkring 500$).

DASY stillede heldigvis en pc til rådighed. Det var en 90 MHz Pentium med 32 MB RAM, 2 GB harddisk og et standard 64 bit grafikkort med 2 MB V-RAM. Vi havde nu alt på plads på hardwaresiden, med en pc, et HMD med tilhørende ultrasonisk tracker (som skulle placeres oven på hovedet), samt en ultrasonisk mus. Som positioneringsdevice valgte vi et joystick. Det lyder måske billigt og useriøst, men det er en meget effektiv og intuitiv måde at bevæge sig rundt på skærmen ved hjælp af.

12.2 Softwareindkøb
Som nævnt tidligere havde vi indsnævret antallet af VR-udviklingsplatform-leverandører til to. Omfattende studier af tilsendt materiale og beskrivelser i "Garage VR" gjorde til sidst, at vi valgte Sense8 WorldToolKit. Paradoksalt nok, så skete det bla. ud fra den betragtning, at det ville komme til at gå hurtigere under Windows(!), idet alle almindelige grafikkort i dag understøtter hardware-acceleration af Windowsgrafik. WorldToolKit kører under Windows, og VREAM under DOS. Det er klar hurtigst at afvikle VR-systemet under DOS, og WTK findes også i en version hertil. Men det kræver at man investerer i et specielt grafikkort til omkring 1800$.

En forskel på de to produkter er, at VREAM understøtter stereoskopi, og WTK ikke. Det var der lidt forvirring omkring, idet beskrivelsen fra Sense8 omtalte alle de platforme hvorpå WTK kører. Af dem er Windows-versionen den eneste der ikke understøtte stereoskopi. Det vil dog være til rådighed i den nyeste version, der kommer på markedet i løbet af 1995. Men i starten troede vi, at vi købte noget som kunne lave stereoskopi. Stereoskopi kræver dog at man har to grafikkort i pc'en.

Sense8 WorldToolKit kostede 795$ og VREAM 495$. I sidste ende købte vi en runtimeversion af VREAM (59$), så vi rent fagligt kunne sammenligne de to programmer. Det gjorde også at vi blev glade for det valg, vi havde gjort i første omgang ved at satse på WTK. VREAM er ikke kun nogle funktionsbiblioteker, men en slags editor hvor man skaber verdener og definerer objekter og deres relationer. Selve programmet skrives i et scriptsprog, der ikke kompileres, men fortolkes.

I demoen var inkluderet nogle ting som vi ikke havde set i Sense8's demoverdener, som f.eks. klassikeren med en hånd som kan flytte rundt på objekter. WTK har dog lagt flere muligheder og er et mere dynamisk miljø at udvikle i, og grafikken i VREAM var ikke lige så god. VREAM har dog en ny version på banen i løbet af 1995, der vil køre under Windows, samt være udbygget kraftigt.

Langt om længe modtog vi WTK, og så var det i gang med at programmere. Vi prøvede først demoerne igennem, hvilket gav os et godt indblik i de funktioner som var til rådighed. Især var vi fascinerede af, at man kunne lave en kasse i et vindue, og samtidig have file-manager fra Windows åbent i et andet vindue, og så vha. drag & drop flytte en grafikfil over på objekter, hvorefter den blev placeret på objektets sider!

12.3 Soft- og hardware-problemer
I starten havde vi meget svært ved at komme i gang med at programmere noget selv. Compilere har udviklet sig betydeligt siden den gang vi sad med PolyPascal version 3.13. Intet ville simpelthen compilere, og vi fik tonsvis af fejlmeddelelser, fordi vi ikke havde inkluderet de rigtige filer og en masse andre ting. Efter mange dages prøvelser fandt vi dog ud at bruge Visual C++, og kunne komme i gang.

Vi brugte også en hel del tid på at sætte os ind i tegneprogrammet 3D Studio. Vi skiftedes til at forberede små kurser i brug af programmet, hvor dagens pensum først blev gennemgået, for derefter at gå over til opgaveløsning. Dette viste sig at være lidt af et vildspor, idet det i sidste ende viste sig ikke at være nødvendigt at medtage figurer, der var dannet udenfor programmet. Men det skyldtes udelukkende den meget afgrænsede opgave vi ønskede at løse, og i andre tilfælde vil det være meget relevant at benyttet AutoCad eller 3D Studio til at tegne objekter med. Mulighederne for dette er yderst begrænsede i WTK.

Undervejs havde vi (selvfølgelig) en masse hardwareproblemer. Pc'en ville halvvejs ikke køre Windows NT længere, sandsynligvis pga. en hardware-fejl. Vi havde også svært ved at få 3D musen til at reagere, men det skyldtes konflikt mellem enhederne der var tilsluttet de alt for få serielle porte på maskinen. Joysticket ville heller ikke virke, så der måtte vi have lydkortet ud for stille jumperne rigtigt, så joysticket blev aktiveret. Alle de ovennævnte ting lyder måske banale, men i virkeligheden tog de oceaner af tid, og man kan endnu en gang undre sig over hvorfor det hele skal være så svært. Hvis vi ikke havde været friske på at flytte jumpere og IRQ-adresser ville vi aldrig have fået systemet til at køre en meter!

12.4 Programmeringsmæssige erfaringer
Programmeringsmæssigt fik vi kraftigt opfrisket vores C-kundskaber. Vi tog udgangspunkt i et lille demo C-program, der fulgte med WTK og byggede flere og flere funktioner på dette (typisk Fedtmule-programmering). Efterhånden lærte vi de forskellige WTK-funktioner og dataformater at kende, og vi fik en fornemmelse for, hvordan vores program skulle struktureres.

Før vi kunne komme særlig langt, måtte vi have styr på biblioteksdatabasen. Den fik vi leveret som en rå tekstfil, så vi måtte først skrive et program, som kunne konvertere denne tekstfil til et format, der kunne anvendes i vores system. Vi måtte også oprette indeksfiler på de enkelte variable for at lette søgningen. Først da denne del af programmeringen var på plads, kunne vi benytte biblioteksdatabasen i vores VR-system.

Næste skridt var at repræsentere databasens objekter i rummet. Her fik vi brug for at oprette og redigere textures 'on the fly', hvilket viste sig at være en tidskrævende opgave, både programmeringsmæssigt og beregningsmæssigt. Det var dog en nødvendighed, hvis systemet skulle kunne repræsentere mere end få hundrede objekter af gangen, for at repræsentere hvert enkelt databaseobjekt som et grafisk objekt ville hurtigt blive for beregningstungt.

Et andet problem var tekst i rummet. I et bibliotekssystem skal der naturligt nok anvendes megen tekst, men WTK understøtter kun tekst dannet af polygoner, hvilket kun giver mulighed for at have ganske lidt tekst af gangen, hvis man vil have en acceptabel framerate. Igen var løsningen at benytte textures, men ved store mængder tekst blev gevinsten i rendering-tid sat til i ventetid, mens programmet genererede textures. Det lykkedes ikke at finde nogen løsning på problemet, men med mere tid til rådighed kunne vi muligvis have optimeret texture-genereringen.

WTK's grafiske funktioner til oprettelse og manipulation af grafiske objekter og navigering via input-enheder viste sig at være lette at anvende, idet de blev kaldt præcis som almindelig C-funktioner. Med relativt få funktionskald kunne vi oprette et rum og flyve rundt i det. Styringen af rummets objekter og brugerens viewpoint var programmeringsmæssigt forholdsvis simpelt, mens det var mere kompliceret at konvertere databasens oplysninger til objekters udseende og placering.

Kommunikationen med brugeren blev kraftigt nedprioriteret, idet vi koncentrerede os om at få selve rummet til at se færdigt ud. Det simple WTK-program, vi tog udgangspunkt i, anvendte et gammeldags tekst-interface, og dette interface byggede vi blot videre på. Resultatet blev selvfølgelig ikke brugervenligt, men det var i det mindste brugbart. Alt i alt må man sige, at den største programmeringsopgave lå i den del af systemet, som virker bag kulisserne. Selve universet og objekterne deri styredes let med WTK-kald, mens dataadministration og texturegenerering var særdeles tungt.

12.5 Evaluering af hardware
Vi kom desværre aldrig til at afprøve et HMD, hvilket jo var et af vores store ønsker. Til gengæld har vi fået en masse erfaringer med andre former for VR hardware. Vores konklusion er, at selv den største standard-pc ikke er tilstrækkelig til at afvikle en professionel VR-applikation, med mindre man er rede til at indgå en masse kompromiser, der går ud over kvaliteten af programmet.

Den store flaskehals ligger i genereringen af skærmbillederne. Et skærmbillede er bygget op af polygoner. Dem kan man meget hurtigt får mange af, og jo flere detaljer - glatte overflader uden hakker - man ønsker, des flere polygoner kræves der. Til at starte med vil et krav om 10000 polygoner på skærmen ad gange være et meget realistisk krav. Men et skærmbillede skal dannes op til 30 gange i sekundet (de fleste HMD'er kræver et NTSC indgangssignal med 30 frames i sekundet), hvilket gør at der skal dannes 300.000 polygoner i sekundet.

Med WTK følger et testprogram, der kan teste ydelsen af et grafikkort. Testprogrammet er bygget op, så det respekterer at grafikkortet eventuelt understøtter hardware-acceleration af nogle specielle kommandoer, samt IGL (Intel Graphics Language), men derudover prøver det at snyde indretninger i grafikkortet, der kunne give et forkert indtryk af dets kapacitet. Det tester hvor mange polygoner grafikkortet kan generere i sekundet på tre forskellige måder. Hvor mange polygoner med textures på, hvor mange gouraud-shadede polygoner og hvor mange almindeligt shadede polygoner, som grafikkortet kan generere i sekundet. Resultaterne ses nedenfor.

Tid (sek.) Frames/sek. Polygoner/sek.
Textured 10,3 7,74 5947
Gouraud-shaded 8,8 9,05 6950
Flat-shaded 4,2 18,05 14524

Som det ses, så er der ikke tale om nogle overvældende resultater. Testen er endog blevet kørt i den utilstrækkelige opløsning 320 x 200 pixels. Årsagen til denne ringe præstation skyldes, at grafikkortet er optimeret til Windows-brug, og da Windows er en to-dimensionel brugergrænseflade, understøtter grafikkortet hovedsagelig 2D grafikgenerering, og ikke 3D.

Hvis vores grafikkort var optimeret mht. at generere 3D grafik i stedet for 2D grafik, så havde resultaterne set ganske anderledes ud. Der findes grafikkort på markedet til priser mellem 1000 - 2000 $, der har tilfredsstillende ydeevener på omkring 100.000 polygoner i sekundet, så en tilfredsstillende løsning ligger inden for rækkevidde. En anden løsning kan være at anvende et operativsystem, som f.eks. Windows NT, der understøtter det anerkendte grafiksprog OpenGL. Den nyeste version af WTK, der udkommer i løbet af 1995, vil ligeledes understøtte OpenGL, og så er det processorernes ydeevne som hastigheden afhænger af.

Vi var positivt overraskede over så hurtigt den indkøbte 3D mus reagerede. Der var praktisk taget ingen følelig reaktionstid i selskab med vores 90 MHz Pentium. Problemet med 3D musen er, at man bliver meget hurtigt træt i arm/hånd af at holde den, på trods af at den næsten intet vejer. Vi havde også regnet med at den ville være mere følsom overfor forstyrrelser, samt have et begrænset operationsområde. Den viste sig tværtimod at arbejde totalt uforstyrret, og man kunne bevæge hånden forholdsvist hurtigt, i vinkler tæt op på 90o i forhold til højtalerne.

12.6 Anskaffelse af litteratur
Vi begyndte året med at søge efter en god bog der kunne give os en introduktion til VR. Vi valgte en bog af der hed "Virtual Reality and the Exploration of Cyberspace" af Francis Hamit [Hamit]. Det viste sig ikke at være et specielt godt valg, idet bogen i vid udstrækning handlede om baggrunden, for hvorfor VR er opstået i en meget bred forstand, og egentlig ikke om VR-teknik og -teknikker som vi havde håbet.

"Garage VR" af Linda Jacobsen [Jacobsen] fik vi fat i forholdsvist hurtigt, og vi har benyttet den som en slags reference- og opslagsværk, og ikke ladet den indgå som pensum. Den giver meget af den introduktion, vi troede vi fik hos Hamit, men er ikke særlig detaljeret. Vi har fundet en masse vigtig information i bogen, men den er meget praktisk anlagt, og behandler teknik som hurtigt er ved at blive gammelt.

Dernæst læste vi 130 sider i Benedikt "Cyberspace" [Benedikt]. Begrebet cyberspace er så grundigt gennemgået og analyseret, at man ikke kan lade være med at ryste på hovedet, når man ser ordet "cyberspace"' nævnt andre steder, fordi det mest benyttes i flæng, uden at forfatteren har det mindste forståelse for kompleksiteten bag. Men det har Benedikt altså!

Vi læste også nogle noter om tredimensional grafik, samt en mængde artikler udgivet af forskere hovedsagelig fra Xerox PARC, omhandlende 3D visualiseringer.

Til allersidst i forløbet faldt vi over en bog der hed "Virtual Reality - through the new looking glasses, 2nd edition" [Pimentel & Teixera]. Hvis vi i dag skulle starte forfra ville vi nok benytte den bog som introduktion til faget. Den har alt det som Hamit ikke havde, og som Jacobsen ikke havde nok af.