VM-NOTAT 2007/11 Prosjektrapport for Pilot 1. Første fase av Virtuelle Møre.

Transkript

1 VM-NOTAT 2007/11 Prosjektrapport for Pilot 1. Første fase av Virtuelle Møre. Av Terje Slinning Knut Helge Skare

2 Forfatter: Terje Slinning Address: Høgskolen I Ålesund, N-6025 Ålesund, Norway Seksjon: ITN tsl@hials.no Web: Tel.: Forfatter: Knut Helge Skare Address: Høgskolen I Ålesund, N-6025 Ålesund, Norway Seksjon: ITN kskar@hials.no Web: Tel.: Rap. serie: Rapport 2007/11 Oppdragsgiver: Rapport tilgang: Rapport status: ISBN: ISSN:

3 FORORD I forbindelse med prosjektet Virtuelle Møre (VM), ble det under prosjektmøte den bestemt at det som pilot for prosjektet skulle utvikles en 3D-modell av terreng og bygninger innenfor området meierikaia til og med campingplassen på Voldsdalsberga i Ålesund. Innenfor dette området skulle det modelleres noen få utvalgte bygninger i forskjellig detaljgrad. Piloten utgjør et viktig grunnlag for opparbeidelse av erfaringer for det videre arbeidet med visuelle modeller i Virtuelle Møre. Den gir oss muligheten til å få bedre erfaring med blant annet egnede grunnlagsdata, datakvalitet, modelleringsteknikker, modellerings verktøy, tekstureringsmetoder og datakapasitet, som igjen kan gi oss svar på en rekke viktige spørsmål i arbeidet med Virtuelle Møre. Det ble satt som mål at piloten skulle være ferdig utviklet innen midten av mai Arbeidet med modellen ble delt inn slik at Knut Helge Skare så nærmere på hvordan vi kunne nyttiggjøre oss de kommunale SOSI-dataene for modellering av terreng, veier og kryss. Terje Slinning skulle se på hvilke data som egnet seg best for fremstilling av 3D terreng, metoder for fremstilling av 3D bygninger i forskjellig detaljgrad, samt å utvikle 3D modellen som danner grunnlaget for Piloten. En testfilm (Pilot_1_2) med utgangspunkt i en meget forenklet 3D- modell fra området, ble i februar 2007 lagt ut på VM s web sider. På VM møte den ble det med hensyn til tidsaspektet, bestemt at også den endelige Piloten skulle presenteres som film.

4 INNHOLD SAMMENDRAG... 5 TERMINOLOGI INNLEDNING MATERIALER OG METODE MATERIALER METODE RESULTATER FORARBEIDE VURDERING AV GRUNNLAGSDATA TILRETTELEGGELSE AV GRUNNLAGSDATA UTVIKLING AV 3D-TERRENGMODELL ALTERNATIV 1: ALT/SOSI ALTERNATIV 2: TERRENG/DEM VEIER/SOSI BYGNINGER/3D PROGRAM UTVIKLING AV VEGER UTVIKLING AV 3D BYGNINGSMODELLER TEKSTURER FORMIDLING AV PILOTEN DISKUSJON KONKLUSJON... 26

5 SAMMENDRAG Hensikten med piloten for Virtuelle Møre har vært å gi deltakerne i prosjektet erfaringer med tilgjengelig datagrunnlag, modelleringsteknikker, modelleringsverktøy, datakapasitet og noen av de muligheter og begrensninger som ligger i utvikling og presentasjon av enkle virtuelle modeller. Piloten er ikke ment som noen form for simulator, og er heller ikke egnet til slik bruk. Intensjon med piloten: Lage en visuell modell av Ålesund øst fra TINE meieri til Volsdalen camping. Skulle ta utgangspunkt i eksisterende situasjon og supplere med modeller laget på bakgrunn av skisser fra arkitekt Frode Sandbakk. Modellere et utvalg av bygningene i det aktuelle området. Vurdere teknologi; hardware, software og metodeutvikling. Vurdere dataformat, datamengder og datautveksling. Piloten fikk en tidsramme fra medio januar til medio mai. Realisert i piloten: Visuell modell av Ålesund øst fra TINE meieri til Volsdalen camping basert på eksisterende situasjon. Modellert terreng også utenfor det aktuelle området for å gi et større helhetsbilde. Et utvalg av bygninger i området er modellert. Testet forskjellige modelleringsteknikker og dataformater. Innenfor den gitte tidsrammen ble det ikke anledning til å gjøre noe med Sandbakk-skissen. Vi valgte å utvide terrengmodellen til å gjelde fra Hessa til og med Spjelkavik, for å øke det visuelle inntrykket av pilotområdet. Detaljeringen med bygningsmodeller begrenset vi fortsatt til innenfor det definerte pilotområdet. Vi benytter ikke LOD-funksjon i vår pilot-modell. Vi er derfor avhengig av at maskinen vi bruker kan håndtere hele datamengden innenfor pilotområdet for å fremstille både modell av terreng, bygninger og ønsket teksturering. Det ble tidlig klart at til tross for investering i det nyeste av datamaskin til formålet, vil en ganske raskt møte begrensninger på hvor detaljerte data som kan nyttes til oppbygging avterrengmodeller. SOSI-dataene vi benyttet hadde en ekvidistanse på 1m og selv for vårt begrensede område ble mengden av polygoner så stor at det til tider ble vanskelig å arbeide med modellen. Stadige avbrudd med krasj i prosesser er noe en må regne med under slikt test-arbeid. Noe av det samme forholdet gjelder for bruk av teksturer. Ortofoto levert av kommunen har en oppløsning på 8000 x 6000 piksler. I programmet 3D max klarte vi å laste maksimum av 15 ortofoto med full oppløsning. Det sier seg selv at vi her måtte redusere oppløsningen betydelig. I den endelige pilot-modellen tok vi med alle 15 ortofotoene med en oppløsning på 1024 x Dette gir en hvis fordreining av proposisjonene i ortofotoet, men ikke mer enn at det visuelt blir bra tilpasset terrengmodellen. Vi kunne alternativt sile SOSI-dataene og begrense høydekurvene som benyttes for terrenggenerering, men det eksisterer også et problem med feilregistrerte data, som gir

6 seg utslag i feil terrengform. Dataene må derfor først feilsøkes, korrigeres og kvalitetssikres før en eventuell redusering foretas og terrengmodell genereres. Vi fant etterhvert ut at det til denne piloten og dens korte tidsramme, var mest hensiktsmessig å benytte DEM (Digital Elevation Modell)-data for generering av terrenget. Vi unngår dermed feilregistrerte data, men får også en mindre detaljert terrengmodell. DEM-data ble levert av Statens Kartverk med en oppløsning på 25x25m. Noe som gir en meget ujamn kystlinje, men med en relativt håndterbar datamengde for vårt formål. Dem-dataene ble delt opp i blokker på samme størrelse som ortofotoenes opprinnelige utstrekning når de hadde sin fulle oppløsning. Dette ble gjort for å lette arbeidet med å legge på ortofoto senere. Videre ble det bestemt at vi ikke skulle fjerne sjøområdene for å få frem kystlinjen. Vi beholdt sjøområdene sterkt redusert, for å unngå problemet med ujamn kystlinje. Ortofotoene vil dermed også teksturere sjøen. Vi laget likevel modellen slik at vi enkelt kan fjerne alle polygoner som utgjør sjø, hvis dette skulle være ønskelig. Kryss og veger ble laget i Gemini Terreng, og eksportert til 3D max i formatet 3Ds. Det er ikke i noen sammenheng slik at det bare er å generer veiene. Et stort arbeid ble lagt ned for å få veilegemene så korrekt som mulig på bakgrunn av SOSI-data. Det samme gjelder arbeidet med terreng og bygninger. I denne rapporten er det anledning til kun å vise noe av det arbeidet som ble lagt ned for å få frem piloten. For at vegene skal kunne nyttes iterrengmodellen, må de syes inn i modellen. Polygoner fra terrenget fjernes for å gi plass til veimodellen. Nye polygoner knytter så sammen vei og terreng. Dette er et meget tidkrevende. En rekke programmer som er spesielt utviklet for behandling av kommunale data, gjør dette automatisk internt i software løsningen. Under vårt arbeid med piloten testet vi noen av disse løsningene også. Problemet med en del slike programmer er at de som oftest har store begrensninger på simulator-funksjonen og er meget kostbare. Vi låser oss da lett opp imot dette firmaets måter å løse problemene på, og deres måte å generere modellene. De ferdige modellene har ofte et properitært dataformat som ikke nødvendigvis så lett lar seg eksportere til andre formater som vi eventuelt måtte finne nødvendig for en realtime simulering. Selv om vi ikke skulle ha med simulator funksjoner i piloten, valgte vi til slutt likevel i denne omgang å benytte en rekke standard 3D programvarer for utviklingen av pilotmodellen. På denne måten skaffet vi oss en mengde med ekstra arbeid, men fikk også mer innsikt i hvilke muligheter og begrensninger som ligger i fremstillingen av 3Dmodellen. Dette var da også noe av hensikten med piloten. Med veiene plassert i modellen ble utvalgte bygninger laget i 3D. Det ble benyttet forskjellige modelleringsteknikker og programmer for å fremstille bygningene, og det ble også lagt vekt på å benytte forskjellige detaljeringsgrader uten noe nærmere spesifikasjon. Vi la også vekt på å ikke ende opp med for mange polygoner på hvert bygg. Vi arbeidet derfor med Low Poly modellering og testet forskjellige programmer til formålet. I tillegg til modellerte bygninger, genererte vi Blokker som representerte alle registrert bygninger i området generert på bakgrunn av kommunale data. Dette gir et mer helhetlig visuelt inntrykk av at vi er i en by, selv om blokkene ikke har form av bygninger med detaljer og tak. For å få mer atmosfære i produktet benyttet vi Dreamscape til skyer og lyssetting. Dette resulterte i en uheldig flikkende virkning på skyene i deler av filmen hvor vi opererte med en nokså høy kameraposisjon. Resultatet ble bedre når kameraet fulgte bakken. Når modellen så var satt sammen, ble det satt opp en animasjon i programmet 3D max. Fra denne animasjonen ble det rendret stillbilder i tga-format, som igjenn ble satt sammen til en film i Adobe Premier. Dette er også et meget tidkrevende arbeid og med

7 vellvillig hjelp fra OSC (Offshore Simulator Centre) fikk vi satt opp en renderpark med til sammen 10 prosessorer som rendret stillbildene. Modellen består av over polygoner, et relativt lavt antall i denne sammenhengen. Den største utfordringen med dett grunnlaget ser ut til å være mengden teksturer. Med en mengde detaljerte bygninger i tillegg til ortofotoene på terrenget, ser vi ut til å ende opp med mer teksturer enn 3D studio klarer å håndtere i en og samme operasjon. Dette resulterer i stadige meldinger med out of memory under forsøk på å kjøre prosesser i 3ds Max. Løsningen ble å sette ned oppløsningen på teksturer i viewporten. Dette gjøres i grafikkdriveren. Det ferdige produktet ble en 170 MB stor film i wmv-format på 3minutter og 42 sekunder. TERMINOLOGI Begreper DEM-data Digital Elevation Modell Rasterbilde av terrenget med høydeinformasjon, ofte generert på bakgrunn av satellittdata. Heighmaps Rasterbilder med høydeinformasjon i forskjellige format som PNG, TER etc. LOD Level of detail Modeller med varierende detaljering, hvor detaljeringen avtar med økende avstand mellom objekt og øye (kamera). Low-poly modellering En mye anvendt modelleringsteknikk hvor en etterstreber modeller med så få polygoner som mulig. Realtime software Programvare for visning av data i sanntid. Rendering Generering av digitale bildedata fra datamodeller. SOSI-data Standardformat for utveksling av digitale kartdata i Norge. TIN Triangulated irregular network Vektorbasert digital datastruktur av terrengoverflaten. Forkortelser SOSI - Samordnet Opplegg for Stedfested Informasjon VM - Virtuelle Møre OSC - Offshore Simulator Centre

8 1 INNLEDNING Denne rapporten omhandler de erfaringer og resultater som er kommet fram under arbeidet med denne første piloten for Virtuelle Møre. I januar 2007 ble det bestemt at vi i Virtuelle Møre skulle utvikle en pilotmodell for i et begrenset område. Gjennom dette arbeidet skulle vi skaffe oss kunnskap om noen av de utfordringene et 3D-visualiseringsprosjekt medfører. I pilotprosjektet skulle vi blant annet teste ut datagrunnlag, modelleringsteknikker og metoder for utvikling av 3D-terreng og bygningsmodeller som senere kan nyttes i en simulatorsammenheng. Rapporten beskriver relativt detaljert utførelsen av dette arbeidet og de valg som vi etter hvert fant det nødvendig å gjøre for å kunne fremstille en pilotmodell innenfor de tidligere bestemte kriterier.

9 2 MATERIALER OG METODE 2.1 Materialer [Data og teknologi som er benyttet i arbeidet.] Følgende grunnlagsdata ble benyttet i prosjektet: Statens kartverk : Digitale kartdata i formatet DEM - Digital Elevation Modell med oppløsning 25x25m for Ålesund området med filnavn 6903_25.dem Ålesund kommune: Digitale tekniske kartdata i SOSI-format med ekvidistanse på 1meter. 15 ortofoto over området med oppløsning på 6000x8000 piksler i jpg-format Vi diskuterte to hovedretninger for fremstillinger av 3D-modeller tilrettelagt for en visuell simulering. Tradisjonell terreng-trådmodell på forhånd generert/utviklet på basis av terrengdata. Trådmodell generert on the fly på grunnlag av heightmaps. På et så tidlig stadium i det Virtuelle Møre fant vi det mest hensiktsmessig å benytte tradisjonell modellering. Alternative metoder Det fins mange veier fram mot en tradisjonell virtuell 3D-trådmodell og vi satte opp følgende alternativer vi kunne velge blant i det videre arbeidet. Alternativ 1 : Hele modellen (Terreng, Veier, Bygninger etc.) utvikles i GIS-verktøy på grunnlag av kommunale SOSI-data Alternativ 2: Terreng genereres av DEM-data fra Statens kartverk. Veier genereres fra kommunale SOSI-data. Bygninger modelleres i egnet 3D-software. Alternativ 3: Hele modellen (Terreng, Veier, Bygninger etc.) modelleres i egnet 3D software Alternativ 4: Terreng genereres i Realtime fra Heightmaps. Veier genereres fra kommunale SOSI-data Bygninger modellers i egnet 3D-software. I piloten valgte vi å se nærmere på alternativ 1 og 2.

10 2.2 Metode Alternativ 1: Alt/SOSI Modellere veier og terreng i sin helhet i programmer som håndterer kommunale SOSI-data, som f.eks.gemini Terreng, ArcGIS eller XfactorGIS. Supplere med bygninger, broer o.l. fra andre 3D-program som 3ds Max, ArkPartner, AutoCAD, ArchiCAD etc. 3D-modellene kan i sin helhet vises i GIS-programmenes interne viewere. De interne viewerne er ofte enkle og har sine klare begrensninger i forhold til visualisering og simulering. For det virtuelle Møre har vi derfor valgt å eksportere den ferdige modellen til et egnede format for visning i eksterne viewere eller for senere bruk i en Realtime applikasjon. Alternativ 2: Terreng/DEM Veier/SOSI Bygninger/3D program Modellere kun veier fra SOSI-data i egnede programmer som Gemini Terreng og Novapoint Veg e.l. Eksportere veiene til et egnet format. Modellere terreng fra Statens kartverk sine grunnlagsdata, som f.eks. DEMdata med en oppløsning på 25x25 meter og evt. supplere med mer detaljert kystkontur. Sammenstille veier og terreng i et egnet program hvor terreng og veger bygges/settes sammen til en modell. Supplere med bygninger og andre 3D- objekt.

11 Software som i større eller mindre grad benyttet til testing og behandling av data i piloten: Gemini terreng 6.4 SOSII2Shape converter (Geodata) ArcGIS Desktop 9.2 XfactorGIS Globalmapper 7.0 Google Sketchup 6.0 Multigen Creator 3.2 Autodesk 3ds Max Adobe Phtoshop CS2 Adobe Premier Pro 2.0 Feeling software ColladaMax Dreamscape 3ds Max plugin Okino Polytrans 3ds Max plugin Verktøy som.feks. ArcGIS, Gemini terreng og XfactorGIS har muligheten til å fremstille 3D-modeller hvor det på grunnlag av kommunale SOSI-data mer eller mindre automatisk genereres terreng, bygninger og veger. Spesielt er XfactorGIS tilrettelagt for dette hvor vi med gode kommunale data innsamlet med tanke på 3D (med blant annet mønelinje data), vil kunne få generert enkle bygninger med tilnærmet korrekt geometrisk form. En vil likevel ikke kunne gjengi komplekse bygninger med meget varierende sammensetning. Google Sketchup og Multigen Creator ble benyttet for fremstilling av bygninger, mens terrenget hovedsakelig ble generert av DEM-data i 3ds Max. Veg-objektene ble generert i Gemini Terreng. Globalmapper behandler en rekke formater og ble nyttet til kontroll, oppdeling og konvertering av grunnlagsdata. Teksturer ble kontrollert, justert og konvertert i Adobe photoshop.

12 3 RESULTATER Forarbeide Innsamling av data Høgskolen har fra tidligere tilgang på DEM-data fra Statens kartverk. Disse ble gjort tilgjenglige for prosjektet. Videre ble det inngått en avtale med Ålesund kommune om bruk av deres digitale kartverk i SOSI-format, samt bruk av de nyeste ortofoto fra kommunen. Tegninger av aktuelle bygninger i området ble innhentet fra arkitekter. Vi ønsket også å motta 3D-modeller fra arkitekter, men dette viste seg noe vanskelig. Det kan virke som om få arkitekter, om noen i det hele tatt, sitter med ferdige 3D-modeller av nyere bygninger i Ålesund. Oppsett av datamaskin Selv om utviklingen av datakraft er stor, er det viktig å ta høyde for behovet for ressurssterke maskiner som arbeidskraft i utviklingen av store og sammensatte 3D modeller. Det kan virke som en aldri får nok prosessorkraft i noen av de mest ressurskrevende prosessene ved fremstilling av 3D-modeller og rendering av filmer. Spesielt gjelder dette bruken av teksturer med høy oppløsning. Prosjektet anskaffet derfor en av de kraftigste bærbare datamaskinene som Dell leverer. En Dell Precision M90 med Xp Pro: Dualcore 2.3 GHz prosessor 2 GB minne Økt virtuelt minne via 3GB switch i boot.ini filen. Nvidia Quadro FX3500M skjermkort med 512 MB minne Quadro driver for 3ds Max 8.0 Installering av nødvendig software og plugins i Dell M90 Følgende nødvendige programvare og Plug-ins ble installert. Xp Pro - Foretrukket fremfor Vista p.g.a mer stabilitet. SOSI2Shape converter (Geodata) ArcGIS Desktop 9.2 Globalmapper 7.0 Google Sketchup 6.0 Multigen Creator 3.2 Autodesk 3ds Max Adobe Phtoshop CS2 Adobe Premier Pro 2.0 Feeling software ColladaMax Dreamscape 3ds Max plugin Okino Polytrans 3ds Max plugin

13 I tillegg ble følgende program benyttet i annen maskin tillhørende ITN ved Høgskolen. XfactorGIS Gemini Terreng 6.4 Vurdering av område Det aktuelle området ble definert fra Meierikaia til Volsdalen camping. Det ble bestemt å modellere de fleste bygningene langs E39 innenfor dette området med prioritet på Tine meierier, Sunnmørsposten, Medi3 og Color Line stadion. For å øke den visuelle virkningen i filmen som skulle utgjøre sluttresultatet, ble det bestemt å øke terrengområdet til å gjelde fra Hessa til og med Spjelkavika. Modellering av bygningsmasse ble opprettholdt til å gjelde innenfor det definerte Pilot 1-området. Vurdering av grunnlagsdata Hvilke datasett som ble benyttet Statens kartverk : Digitale kartdata i formatet DEM - Digital Elevation Modell med oppløsning 25x25m for Ålesund området med filnavn 6903_25.dem Ålesund kommune: Digitale tekniske kartdata i SOSI format med høydekvoter på 1m. 15 ortofoto over området med oppløsning på 6000x8000 piksler i jpg format Konvertering av datasettene. DEM-dataene kan nyttes slik de er direkte i programmer som Global mapper. SOSI-datene kan også nyttes direkte i for eksempel Gemini Terreng og XfactorGIS, men for videre å kunne nyttes i ArcGIS eller Globalmapper, må de konverteres til shape. Dette gjøres med SOSI2shape levert av Geodata as. Det er her viktig å nytte siste versjon av konverteringsverktøyet. Jpg-ortofotoene fra Ålesund kommune har en oppløsning på 8000x6000 piksler, og må reduseres for å kunne nyttes i 3D-modellen. Ellers ville modellen bli altfor tung å kjøre og dermed kreve for mye ressurser av datamaskinen vi nytter. Bildene ble deror redusert i Adobe Photoshop til en oppløsning på 1024x1024 piksler. Dette gir en noe fordreining av bildenes originale utstrekning, men ikke mer en at det er akseptabelt visuelt i dette prosjektet. Vurdering og kvalitetskontroll av SOSI-data SOSI-dataene ble først visuelt sjekket i programmet SOSIvis fra Statens kartverk. Datasettene ble så konvertert til shape-format, og ytterligere kontrollert i ArcGIS. Ved å studere datasettene i 3D-visningen i ArcGIS ser en lettere eventuelle feilregistreringer i Z aksen. Det ble slik tidelig klart at datasettene med høydekvoter og takutspring fra kommunen inneholdt en god del feil. Enten som feilregistrerte, manglende eller verdier plassert i feil kolonne for høyde z. Dette ble ytterligere understreket ved tester i XfactorGIS, som viste at feilene forårsaket betydelige deformeringer av de modellene som automatisk ble generert på grunnlag av disse datasettene.

14 Hvilke datsett som ble valgt til alternativ 1 XfactorGIS For modelleringsalternativ 1 hvor vi ønsket å nytte XfactorGIS, ble følgende datasett i Euref 89 koordinatsystem 22 benyttet. 1504terreng.sos 1504bygninger.sos 1504vegsituasjon.sos Hvilke datasett som ble tatt med i alternativ 2 For modelleringsalternativ 2, med bruk av 3ds Max for terreng-generering, nyttes DEM datasett levert av Statens kartverk i UTM WGS84 sone 32 Nordre hemisfære og ortofoto levert av Ålesund kommune i Euref 89 koordinatsystem 2. Terrengdata 6903_25.dem Ortofoto jpg jpg jpg jpg jpg jpg jpg jpg jpg jpg jpg jpg jpg jpg jpg

15 Tilretteleggelse av grunnlagsdata Hva ble gjort med grunnlagsdataene i ArcGIS for å få frem en vurdering av SOSI datasettene SOSI-dataene fra Ålesund kommune ble konvertert til shape for enklere å kunne vurdere kvalitet. I ArcGIS kan vi også få frem en 3Dterrengmodell i TIN format, et format vi i dette tilfellet ikke ønsket å benytte til annet enn en tidelig kontroll og vurdering av SOSI-dataene. SOSI-dataene ble klippet i ArcGIS til det aktuelle området slik at ikke datamengden ble uhensiktsmessig stor. I ArcGIS ble SOSIgrunnlagsdataene vurdert visuelt. Feilregistrerte data blir lett synlig i 3D-visning. Ved videre å studere tabellene ser en hva som forårsaker feilene. Noen data er registrert i feil kolonne mens andre er gitt feil verdier. Bildet viser hvordan feilene blir synlige i ArcGIS. Noen av dataene mangler totalt z-verdi, mens andre har enkelte vertex med manglende z verdi. Dette medfører at linjer dropper ned mot 0 verdi og gir åpenbare feil i terrenget. Det ville medføre et stort arbeid å rette disse feilene, og dette medvirket til at vi valgte å nytte DEM data som grunnlag for terrenget til Pilot 1. En eventuell bruk av SOSI-data som grunnlag terrengmodell kan bli aktuell i en senere pilot. Hva ble gjort med DEM dataene DEM (Digital Elevation Modell) dataene ble hentet opp i Globalmapper og kontrollert for feil. DEM-dataene ble så delt opp i nye og mindre områder tilpasset størrelsen på ortofotoene mens disse ennå hadde en den opprinnelige oppløsningen på 8000x6000 piksler. De nye områdene ble så navngitt lik navnet på ortofotoene de var tilpasset. Oppdelingen sikrer en lettere overlegging av ortofotoene i 3ds Max på et senere tidspunkt i modelleringen av terrenget. Vi vil da også få muligheten til å utelate enkelte områder hvis datamengden skulle bli for stor og om vi finner det hensiktsmessig å redusere det modellerte området.

16 Hva ble gjort med ortofotoene. Ortofotene ble reusert fra 8000x6000 piksler til 1024x1024 piksler. Dette for å redusere datamengden slik at den ble håndterbar for grafikk-kortet og at størrelsen ble delelig med 2. Derfor 1024x1024 og ikke et forhold som opprettholdt forholdet mellom x og y. Oppløsninger delelig med 2 er lettere håndterbart for grafikk-kortene, samt at dette kreves av DDS-bildeformatet hvis en ønsker å bruke dette. Dette formatet gir ytterlige fordeler da nvidia baserte grafikk kort leser DDS formatet direkte med riktig origo. Ved andre format vil grafikk-kortet måtte utføre en origo korreksjon før visning. Endringer gjort i SOSI-dataene fra kommunen i.f.m. konstruksjon av veger Høydefeil i SOSI-terreng- og vegdata fra kommunen må rettes/korrigeres før konstruksjon av vegobjekter. I pilotprosjektet valgte vi for enkelhesskyld å slette alle 0 -data (alle kartobjekter med høyde=0, med manglende høyde) og objekter med helt opplagte feilregistrert høydedata ( ekstremverdier ). Alternativ med en modell uten flater som representerer sjødata, men med god kystlinje. Modellen vi laget inneholder ikke sjødata eller kystlinje, men kun landdata og flater som representerer sjøområder. Ved import av DEM-data til 3ds Max benyttes en plugin-importer som skiller mellom land- og sjødata. Vi kan dermed enkelt fjerne sjødataene fra landdataene hvis ønskelig. Ved å nytte kystlinjedata fra SOSI-datasettet kan vi manuelt justere de vertexene som blir igjen langs en naturlig kystlinje. Videre vil vi kunne nytte for eksempel en dynamisk sjø fra Dreamscape for en bedre visuell opplevelse av modellen. Dette alternativet ble det ikke tid til å utføre i Pilot 1.

17 Utvikling av 3D-terrengmodell Alternativ 1: Alt/SOSI Kommunens SOSI-data ble benyttet i programmet XfactorGIS og relativt raskt kunne en 3D-modell over det utvalgte området fremvises i en intern viewer. Feilregistrerte eller misstilpassede data (markert i bildene med røde piler) ble fremtredende og illustrer godt hvor viktig det er med data innsamlet for formålet. I dette tilfellet er det tydelig at dataene ikke er rikelig tiltenkt benyttet i en 3Dsammenheng. Flere av 3D-objektene kan beskrives med følgende forhold: Bygninger med kompleks bygnings- /takflate (mangler møneretning) Bygninger som ikke er flatedannet Bygninger uten høyde (0-verdi) Veger, broer/ramper Bekker med en og samme høyde over en lengde Terreng med uønskede utslag For mange polygoner genereres og selv modeller over små områder kan bli tunge og kjøre. De egner seg dermed lite for modellering av større områder, og kjøring i realtime- applikasjoner hvor fokus ofte er på lowpoly modellering og hvor detaljene skapes ved avansert teksturering og shader-teknikk. Manglende linjer i terreng ved enkelte områder som krever mye etterarbeid ved å digitalisere inn nye egnede linjer å triangulere mot. Data registrert i feil kolonner må rettes. Manglende data må registreres, digitaliseres. I områder med for tett datamengde må datamengden reduseres. Også sjø/havflaten trianguleres. Til tross for feilene er dette en meget rask og nokså enkel måte å visualisere de kommunale dataene i en 3D-modell. Som nevnt begrenses vi av at resultatet må vises i en intern viewer eller en ekstern viewer levert av samme programprodusent. Vieweren har så langt store begrensninger med hensyn til simuleringer og det vil være tidkrevende med retting av feilene i grunnlagsdataene. Dette lar seg imidlertid gjøre og må vurderes opp mot hvor tidkrevende prosessen for alternativ 2 er. Modellen vises med bygninger, ferdige veier og med dynamisk sjø. Mer detaljerte bygninger må også her modelleres i programmer tilsvarende 3ds Max for så å plasseres i senen. Det vi først og fremst sparer tid på med denne metoden er generering av terreng og vei. Med denne løsningen slipper vi unna det veldige arbeidet med å sy inn vegmodellen i terrengmodellen, slik vi må i alternativ 2. Så langt skjemmes imidlertid veiene av kanter og knekker i vegbanen forårsaket av mangler i grunnlagsdataene. Dette kan muligens rettes ved å justere, korrigere eller legge til data i grunnlagsdatasettet. Vi valgte imidlertid heller å se

18 nærmere på alternativ 2 som gir oss noe større frihet med valg av hvordan vi vil benytte sluttresultatet. Problemet med høy visuell kvalitet på 3D-objekter og terreng direkte generert på kommunale SOSI-data gjenstår. Heller ikke XfactorGIS løser dette uten å måtte gå via programmer som f.eks. 3ds Max. Alternativ 2: Terreng/DEM Veier/SOSI Bygninger/3D program Import av de oppdelte DEM-dataene i 3ds Max. Dem2max er en plugin til 3ds Max som håndterer filer av DEMformatet. Bildet viser hvordan datagrunnlaget blir seendes ut etter import. De grønne områdene er land og de blå er sjø. Når DEM-filene vi lagde importeres vil vi se at de plasserer seg noe fra hver andre. Det oppstår et mellomrom mellom de forskjellige områdene som forårsakes av Globalmapper i det vi stykker området opp i mindre deler. Vi har ikke mistet noe data, så dette løser vi enkelt ved å flytte de enkelte områdene sammen igjen i 3ds Max. Optimalisering av modellen. Modellen vi nå har består av unødig mange polygoner (ca 92000) og bør reduseres. Når vi foretar reduksjonen for eksempel med optimizer, vil vi oppleve at modellen blir noe mer kantete. Dette korrigerer vi med enten relax eller smooth. De forskjellige seksjonene av sjø og land reduseres en og en. Vi har valgt å beholde sjø, for å legge ortofoto også på dette. Sjø reduseres naturligvis mer enn land og hvert enkelt landområde tilpasses avhengig av hvor kupert det er. Utvikling av veger Det finnes ulike verktøy for konstruksjon av veger i 3D. I Norge er NovaPoint Veg og Gemini Terreng de to mest brukte planleggings-/prosjekteringsverktøyene for veger. Verktøyene er laget for planlegging og konstruksjon av nye veger, men i piloten benyttet vi Gemini Terreng til konstruksjon av eksisterende veger. De kommunale SOSI-dataene ble benyttet som bakgrunn ved konstruksjon av den horisontale veglinjen. SOSI-dataene fra Ålesund kommune inneholdt kun linjer for vegens avgrensning (vegkanter) og disse linjene ble brukt for manuell konstruksjon av senterlinjen på skjerm.

19 Vertikalkurvaturen for veglinjene ble også manuelt konstruert på skjerm. Vertikalkurvaturen ble lagt på terrenget med unntak av steder vi klart avduket feil i terrenget. Vegens utstrekning (bredde), såkalt normalprofil, ble videre definert. Resultatet av dette var vegkropper som programmet automatisk setter inn i terreng. I overgangen mellom de ulike vegkroppene må det defineres rundkjøring eller kryss. Gemini Terreng har en egen modul for generering av kryss. Dette måtte gjøres kryss for kryss og selv i dette begrensede området viste dette seg meget komplekst. I tillegg til kryssene måtte en sette opp at programmet skulle stoppe vegkroppene ved broer og ramper. Resultatet av arbeidet var vegkropper og kryss skjært inn i terrenget. Vegobjektene ble så eksportert som et samlet objekt via 3ds-format og vrml-format. Her gjorde vi forsøk både med eksport av veg og terreng samlet samt vegen alene

20 Kobling av terreng og vei i Creator Veikroppene som ble generert i Gemini Terreng hentes inn i Creator i 3ds-format. Fra tidligere har vi også importert Terrenget uten teksturer fra 3ds Max også i 3ds-format. Vi benytter med fordel 3Ds eksporten fra pluginen Polytrans i 3ds Max i stedet for standard 3Ds-eksport. Feil og mangler fra veiobjektet laget i Gemini Terreng må korrigeres. Det oppstår lett huller mellom polygoner, og feiltolkede høydedata i kryss med spesielt krappe svinger. Broer og eventuelt tunneler konstrueres og settes sammen med vegen. Med hjelp av det svært nyttige Follow me tekstureringsverktøyet i Creator tekstureres veiene relativt lett. Vegmodellen sys så manuelt sammen med terrengmodellen. Dette er meget tidkrevende og ved en eventuelt tilsvarende prosess senere må det legges arbeid i å finne mer automatiserte og egnede metoder. Det hele eksporteres så til 3ds Max for ytterligere teksturering og scene-oppsett. Teksturering med ortofoto. Skjermkortet på vår maskin takler maks 10 ortofoto med maks oppløsning på 8000x6000 piksler. Vi skal ha plass til 12 ortofoto samt en mengde teksturer på bygninger etc. De allerede reduserte ortofotoetene draperes på terrengmodellen. Hvert bilde passer perfekt til de forskjellige terrengmodulene med sjø som vi på forhånd tilpasset i Globalmapper. Fjerner vi sjøen før tekstureringen vil vi ikke få ortofotoene til å passe uten en nitidig manuell tilpassning.

21 Utvikling av 3D bygningsmodeller Bygninger kan utvikles i forskjellige egnede 3D-program som for eksempel 3ds Max, Sketchup, Multigen Creator, ArchiCAD, AutoCAD etc. Vi valgte å teste med Sketchup som har en populær gratisversjon med et meget brukervennlig grensesnitt og Multigen Creator. Et meget kostbart profesjonelt verktøy med en meget god bygnings-wizard. Import av polygon fra SOSI grunnlag til Creator. I creator kunne vi med fordel benyttet omrisset fra bygningene i SOSI-dataene fra kommunen, men Ålesund kommune nytter takutspring som flatedefinisjon av bygningsflaten og ofte uten møneretning. Kompliserte takflater er ikke registrert med nok data og det blir derfor lettere å digitalisere omrisset på nytt på grunnlag av ortofoto. Ortofotoene importeres derfor inn i Creator og det nye omrisset av de bygningene som skal modelleres digitaliseres inn. Modellering av bygninger med Building wizard i Creator. De nye flatene benyttes sammen med vurderinger av taktype, møneretning, høyde etc. fra bilder tatt av bygningene direkte i bygnings-wizarden. Slik kan hele kvartaler og bydeler modelleres i Creator. Høydeplasseringen av bygningen må i dette tilfellet gjøres senere ved en manuell tilpassning av hver bygning når bygningsmassen settes inn sammen med terrenget. Valg av eksport-format. De ferdige bygningene eksporteres i dette tilfellet i Wavefront obj-format som passer for import og videre teksturering i Sketchup. Tekstureringen kunne selvsagt vært foretatt i Creator, men siden flere av bygningene også skal bygges i Sketchup, så fant vi det hensiktsmessig å ta all tekstureringen der. Ved Obj-eksporten fra Creator må vi dessuten selv ta hensyn til stien hvor teksturene ligger. Ved å eksportere modellene fra Sketchup, vil vi kunne nytte Collada-plugin som samler alle teksturene for hver eksport i en felles mappe. Modellering av bygninger i Google Sketchup. Det er umulig å lage komplekse bygninger som f.eks. Color Line Stadion med en wizard. Kompliserte bygninger ble derfor bygget i Google Sketchup som ikke har noen bygningswizard. Programmets menyer er enkle og brukervennlige. Det går relativt greit å forme kompliserte bygninger med sammensatte takkonstruksjoner. Ved å legge tekstur på en bygningsflate kan en tegne detaljer som vinduer, balkonger etc. direkte på modellen. Et Follow me verktøy forenkler mye av tegningen. Ved å lage en flate med tverrsnitt av f. eks. tribunen vil en kunne dra formen rundt hele stadionet. Sketchup muliggjør også tegning i løse luften, slik at en ikke er avhengig av mer enn et forankringspunkt for å tegne for eksempel en bue.

22 Valg av eksport-format. Ved å nytte Collada-plugin for Sketchup vil vi enkelt kunne eksportere modellene til 3ds Max. Vi trenger da selvfølgelig en Collada-importer i 3ds Max. Collada-eksporteren i Sketchup samler teksturene den trenger til modellen i en egen mappe sammen med modellfilen. Den reduserer samtidig størrelsen på teksturfilene idet filene blir konvertert og komprimert til jpg-format. Oppløsningen blir beholdt. Dette forenkler samlingen av modeller i samme mappestruktur. Med hensyn til størrelse på filene kunne vi like godt nyttet Wavfront-object. Test av Sketchups Photomatch. Sketchup pro har enda en mulighet for modellering av bygninger med verktøyet Photomatch. På bakgrunn av ett eller flere bilder tatt rett mot hjørnene på bygningene, tegner vi 3D-modellen direkte inn i bildene. Teksturene ekstruderes så ut fra bildene. Dette fungerer greit hvis modellen er enkel, relativt liten og skal benyttes i sketchup slik den er. Men det viste seg fort at dett ikke passet for vårt formål. Til en enkel modell av en firkantet blokk og på basis av 2 bilder, genererte photomatch opp mot 600 små og mellomstore teksturer. Verre var det at alle teksturene også fikk helt vilkårlige oppløsninger. Ingen av dem delelig med 2 og modellen ble således svært ressurskrevende for grafikk-kortet. Test av Imagemodeler. Imagemodeler er et spesialisert program for tegning av 3D-miljøer direkte ut fra bilder, noe tilsvarende Photomatch men mer profesjonelt. For dett programmet gjelder mye av det samme som for Photomatch. Teksturoppløsninger i alle størrelser og forhold, samt en mengde teksturer selv fra enkle bygninger. I tillegg kreves det mye mer av kalibreringen mellom de forskjellige bildene. Dette kan til tider være nokså frustrerende. Til vårt bruk, hvor vi ønsker kontroll på oppløsningen i teksturene og med minimal filstørrelse, er det best å holde seg til tradisjonell 3D-modellering. Dette også fordi vi skal benytte modellene vi lager i en sammensatt sene med flere modeller og terreng. Teksturer Fotografering. Som grunnlag for teksturerering av bygningene må vi ut å ta bilder av fasadene. Bildene gir oss også et godt inntrykk av fasadenes form, høyde og plassering. Det er viktig at bildene som skal nyttes til teksturer tas under mest mulig gunstige og like lysforhold for å unngå skygger, og med minst mulige fremmed legemer i veien for selve bygningen. Vi må likevel påregne en hel del redigering i for å oppnå et best mulig resultat. Dette er et viktig og tidkrevende arbeid som sørger for gode rene teksturer, men som ikke nødvendigvis legges så godt merke til av senere brukere. Når en ser på en husfasade ville en lett legge merke til at det er unaturlig med for eksempel en bil i fasaden, men når bilen er redigert bort er det ingen som tenker over at det er lagt ned arbeid i dette. Det bør etterstrebes å ta bildene så rett som mulig direkte på fasadene, men det vil likevel bli nødvendig med senere justeringer. Bildene tas av hele fasadesider, men også av detaljer som er viktige å få med. Tak og lignende har et repeterende mønster, og her rekker det ofte å ta bilde av et lite område som senere behandles i f.eks. Photoshop.

23 Behandling av foto i Adobe Photoshop. I Photoshop redigerer vi bildene og gjør dem om til egnede teksturer. Lys, farge og kontrast justeres og teksturens omriss og innhold bestemmes. Fremtredene skygger og fremmed legemer redigeres bort. Skjevheter i bildet p.g.a. kameravinkel korrigeres med et av verktøyene i Free Transform. En egnet oppløsning delelig med 2 bestemmes for hver enkelt tekstur. Teksturen lagres så i egnet format og mappestruktur i forhold til modellen(e) de skal benyttes med. På noen av teksturene kan en med fordel benytte alpha kanal. Denne kanalen sørger for gjennomsiktige partier i teksturen. Eksempler på dette kan være mellom grener og blader i trær eller kompliserte fasadedetaljer som stikker ut fra bygningen og hvor en ikke ønsker å legge arbeid i å modellere selve detaljene. Mengde teksturer i en sene. For å få kontroll over mengden teksturer som kan benyttes i en sene, bør en beregne mengden av grafisk minne de samlede teksturene tar opp. Hver komponent i teksturen av rød, grønn, blå, Intensity eller alpha-kanal tar opp 1 byte minne hver. Da vil for eksempel en 1024x1024 piksel rgb-tekstur trenge 1024x1024x3 = (ca 3MB) med minne av et grafikk kort med totalt kanskje 512 MB tilgjengelig. Slik må da dette regnes ut for hvert av teksturene i senen som vises på skjermen i samme tid. Hvis en i tillegg benytter MipMap og kanskje Trilinear-filter (noe en absolutt bør for å redusere teksturstørrelsene på avstand og å hindre flickering ) ganges behovet for minne ytterlige med 1, MipMaps sørger for en reduksjon av teksturer på avstand. For eksempel fra 1024x1024 til 512x512 til 256x256 etc 8 ganger jo lengre vekk kameraet er fra teksturen. MipMapping ligger lagret i teksturfilen og kan settes i Photoshop med en plugin levert av Nvidia. I Multigen Creator lagres dette meget enkelt i egenskapene for hver tekstur. Formater jpg, tga, dds Vi kan nytte flere bildeformater. Mye brukt er jpg, tga og dds. Jpg er et komprimert format og er enkelt å nytte. Tga er ukromrimert og gir best kvalitet, men krever alt for mye minne. DDS er komprimert på en måte som leses direkte av nvidia baserte grafikkkort. For DDS-formatet sammenfaller origo direkte med hvordan grafikk-kortene leser bildeinformasjonen. Dette i motsetning til de fleste andre formater hvor grafikk-kortet først må orientere origo. DDS-formatet krever dermed mindre ressurser av grafikkkortet. Vi har imidlertid benyttet jpg i Pilot 1 da Collada-eksporten fra Sketcup nytter dette formatet.

24 Formidling av piloten Samling av 3D-modeller i 3ds Max. De ulike bygningsmodellene samles sammen med terrengmodellen og vegmodellen i 3ds Max. Bygningene plasseres enkeltvis manuelt i x, y og z aksene. Terrenget vil ikke sammenfalle helt opp under bygningsmodellene og det blir dermed en vurdering om hvor mye arbeid en skal legge i redigering og tilpassningen av terrenget. I denne piloten valgte vi ikke å vektlegge dette. På grunn av denne modellens utstrekning, størrelse og mengde teksturer ble det ikke plass til mer enn de bygningene vi la inn. Vegmodellen ble teksturert og sydd sammen med terrenget i Creator. Bygningene fra sketchup og creator, ble importert i Collada-format, mens bygningsklossene fra ArcGIS ble importert i 3ds format. Flere detaljerte bygninger ville redusert ytelsen til 3ds Max og med stor sannsynlighet ført til at programmet krasjet med meldingen Out of memory både under renderingen av filmen eller under arbeid med modellene. Dette opplevde vi da også flere ganger. For i det hele tatt og kunne arbeide med modellen slik den nå var, ble det nødvendig å redusere kraftig på 3ds Max-innstillinger for hvordan modellen vises i viewportene. Blant annet ble det gjort innstillinger på Maxtreme display-driveren for 3ds Max levert av nvidia. Med alle elementer samlet, gjenstår arbeidet med å lage animasjonen. I seg selv et meget tidkrevende arbeid. Bruk av Dreamscape. For å øke realismen ble 3ds Max plugin Dreamscape benyttet for å legge atmosfære til senen. Dette så bra ut i 3ds Max med skyer og atmosfære, men når filmen ble rendret, fikk skyene en utilsiktet effekt som gjorde dem utydelige med forstyrrende flimring. Bruken av Dreamscape ble derfor i denne omgang ikke vellykket. Valg av format tga. Ved rendring av filmen i 3ds Max ble det bestemt at vi skulle satse på ukomprimerte tgafiler med oppløsning på 720x576. Dette gir bedre kvalitet på filmen, men øker samtidig betydelig tiden det tar å rendre hvert enkelt bilde. I tillegg økes også lagringsstørrelsen på både bilder og film. Hvert enkelt bilde ble på nesten 1,3 MB. Oppsett av animasjon. Animasjonen ble satt opp i 3ds Max med rendring av totalt 6600 bilder. Rendringen av tga-filene er en meget tidkrevende prosess og for 1 prosessor tok det ca 1,5 min pr bilde. Til sammen blir da dette 1,5 x 6600 = 9900 min = 165 timer = ca 7 døgn. Her måtte det sterkere lut til. Vi måtte sette opp en renderpark.

25 Rendring i 3ds Max - Renderpark. En renderpark består av flere datamaskiner i et nettverk som samarbeider om å rendre bilder. Operasjonen styres i dette tilfellet av 3ds Max Backburner. En maskin er satt opp som server som fordeler oppgaver til flere slaver. Flere maskiner kan dermed samtidig arbeide med hver sine tildelte piksler i et stort avansert digitalt bilde, eller som i vårt tilfelle arbeide med hele tildelte bilder av en sekvens. Vi satte opp 4 maskiner med dual core-kjerner, altså 8 prosessorer som arbeidet med hver sine tildelte oppgaver. Hele prosessen tar da 165 timer : 8 = ca 20 timer. Med tanke på at vi ikke nødvendigvis kan regne med å bli helt fornøyd med første resultat og må kjøre prosessen flere ganger, er dette fortsatt lang tid. I tillegg viste det seg at flere av de rendrede bildene ble sorte eller lyssvake. Vi vet ikke med sikkerhet hva som forårsaker dette, men via forum på nettet ser vi at vi ikke er de eneste med tilsvarende problemer. Det hevdes fra flere hold at 3ds Max Backburner er noe ustabil. Noen hundre bilder måtte dermed rendres opp igjen for å få et tilfredsstillende resultat. Selv med en renderpark tar prosessen derfor fort et par uker. Rendring i Adobe premier. Etter rendringen til tga-bilder i 3ds Max settes bildene sammen (rendres) til en film i Adobe Premier. Bildene ble her eksportert via Adobe Media Encoder til wmv-format i oppløsning på 720x576 med 30 fps. og max bitrate på Bildekvaliteten ble satt til 100%. Valg av format wmv. Den ferdige animasjonen ble på over 170 MB i wmv-format. Wmv ble valgt fordi dette formatet kan leses av de fleste datamaskiner med windows mediaplayer installert. I tillegg gir dette formatet bra komprimering med relativt god kvalitet. Prosessoversikt Følgende skjema gir et bilde over hvilken prosess som ligger til grunn for produktet vi til slutt endte fikk frem i Pilot 1.

26 4 DISKUSJON Intensjon med piloten: Lage en visuell modell av Ålesund øst fra TINE meieri til Volsdalen camping. Skulle ta utgangspunkt i eksisterende situasjon og supplere med modeller laget på bakgrunn av skisser fra arkitekt Frode Sandbakk. Modellere et utvalg av bygningene i det aktuelle området. Vurdere teknologi; hardware, software og metodeutvikling. Vurdere dataformat, datamengder og datautveksling. Piloten fikk en tidsramme fra medio januar til medio mai. Realisert i piloten: Visuell modell av Ålesund øst fra TINE meieri til Volsdalen camping basert på eksisterende situasjon. Modellert terreng også utenfor det aktuelle området for å gi et større helhetsbilde. Et utvalg av bygninger i området er modellert. Testet forskjellige modelleringsteknikker og dataformater. Innenfor den gitte tidsrammen ble det ikke anledning til å gjøre noe med Sandbakk-skissen. Vi kan vel si at vi ikke helt oppnådde de målsetningene vi hadde innenfor den tidsrammen vi arbeidet i. Modellen er produsert, men kan foreløpig kun vises som film. Vi mangler en egnet viewer for å kunne vise modellen i sanntid. 5 KONKLUSJON Alternativ 1 viser en effektiv og rask måte å få frem en 3D-modell basert på digitale kommunale data. Resultatet blir relativt akseptabelt, men dette er ikke nok hvis en ønsker en detaljert 3Dmodell av høy kvalitet. Feil i datagrunnlaget forsterker inntrykket av en ufullstendig og utilstrekkelig modell. For å få et bedre resultat er det helt nødvendig med betydelige utbedringer på datagrunnlaget eller datasett av høyere kvalitet. Som vist ved FKB data versjon 4.0, Illustrert ved dette bildet. Likevel blir det nødvendig å supplere med detaljerte modeller utarbeidet i programmer tilsvarende 3ds Max og Sketchup. Begrensninger i vieweren med hensyn til simuleringsoppgaver bidrar også til at denne løsningen oppleves som noe snever for mer avansert 3d-simulering. Alternativ 2 er en meget ressurs- og tidkrevende metode, men den gir noe større frihet for hvordan modellen senere kan nyttes. I tillegg kontrollerer en flere aspekt av prosessen selv. Bruken av DEM-data for terreng-generering gir et mindre detaljert

27 terreng enn en ville oppnå med SOSI-data, men en får derimot et datasett med mindre mulige feilkilder. Det vil imidlertid bli interessant å se hvilke datasett som best kan nyttes i senere forsøk med alternativ 4; bruk av heightmaps. Modellen vi fikk laget med alternativ 2 er slik som den nå fremstår, lite egnet for videre utbygging med mer detaljerte bygninger og større områder. Mengden av teksturer i modellen med høy oppløsning fører til gjentatte problemer med Out of Memory meldinger og krasj av 3ds Max. En bedre løsning ville kanskje vært å benytte lavere oppløsning på bygningsteksturene og ortofotoene, benytte mipmaps og DDS format og dele modelllen opp i mindre områder som senere samles i en annen viewer for oppsett av senen. Da i et program som nytter seg av LOD for redusert ressursbruk og som benytter et filformat som vi kan eksportere fra 3ds Max. Hvis en skal nærme seg noen konklusjon etter Pilot 1, så vil det måtte understrekes at modellen er meget resurskrevende og at den slik den nå fremstår må igjennom store strukturendringer før en eventuell videre utvidelse av området og bygningsmassen. Det kan vel også så langt konkluderes med at prosessen etter alternativ 2 slik den nå er beskrevet, ikke er god nok i seg selv. Prosessen trenger flere endringer for å kunne benyttes i en større sammenheng. Aktuelle endringer kan være: Viewer egnet til formålet med simuleringsmuligheter Muligheter for Realtime kjøring med dynamisk sjø og atmosfære. Bruk av LOD Level of detail DDS teksturer med mipmap Bestemmelse for størrelse på teksturer i forhold til detaljgrad i modellen. Bedre metoder for generering og integrering av veier Inkludering av sjødata/batymetri (bunnforhold) Metode for å opprette korrekte kystlinjer Metode for korrigering av terreng ved plassering av bygningsmodell. Utredningen av alternativ 4 vil kunne tilføre mer kunnskap om 3D-modellering av landskap for bruk i simuleringer. Det vil gi oss noe mer erfaringen med en løsning som også i større utstrekning benyttes av spillindustrien. Målet er å samle noen av erfaringene fra måten spillindustrien bygger sine modellverdener med GIS-kompetanse og datakilde-kunnskap.