Onderzoek naar de verwerking, uitwisseling en visualisatie van 3D-data met diverse opslagformaten

Opleiding Geografie en Geomatica Master in de Geomatica en Landmeetkunde

Onderzoek naar de verwerking, uitwisseling en visualisatie van 3D-data met diverse opslagformaten

Sarah Van Muylem

Aantal woorden in tekst: 23 604 Academiejaar 2012 – 2013

Prof. Dr. Ir. Alain De Wulf, vakgroep Geografie Begeleider: Coen Stal, vakgroep Geografie

Masterproef ingediend tot het behalen van de graad van Master in de Geomatica en Landmeetkunde

WOORD VOORAF

Een masterproef schrijven is niet vanzelfsprekend. Gelukkig heb ik veel hulp en steun gekregen van de mensen rondom mij. Daarom wil ik hier graag een woordje van dank richten aan de mensen die mij geholpen hebben bij de verwezenlijking van mijn thesis.

Als eerste wens ik mijn promotor, Prof. dr. ir. Alain De Wulf te bedanken voor de begeleiding tijdens dit onderzoek en het aanreiken van dit onderwerp.

Voor advies, begeleiding en het zoeken naar oplossingen zou ik graag Coen Stal bedanken. Bij hem kon ik steeds terecht met mijn vele vragen tijdens het onderzoek. Ook Timothy Nuttens dank ik voor de aangeboden hulp.

Graag zou ik nog enkele vrienden en familieleden willen bedanken. Vooreerst mijn ouders die mij de kans hebben gegeven om deze opleiding te volgen en me steeds gesteund hebben. Mijn vriend Tim dank ik voor de vele aanmoedigingen, advies, geduld en begrip. Verder wil ik ook een woord van dank richten aan Evelyne, Leen, Anneleen en Debby voor het grondig nalezen van mijn thesis. Bart en Geert bedank ik voor het uitlenen van hun studiemateriaal dat mij geholpen heeft bij het programmeren in Java. Tot slot richt ik graag nog een dankwoord aan al mijn medestudenten voor de vele leuke momenten tijdens de opleiding.

i

INHOUDSOPGAVE WOORD VOORAF .................................................................................................................... i INHOUDSOPGAVE .................................................................................................................. ii LIJST VAN FIGUREN ............................................................................................................. iv LIJST VAN TABELLEN........................................................................................................... v 1.

INLEIDING ....................................................................................................................... 1

2.

METHODE EN MATERIALEN ....................................................................................... 4 2.1

3.

Bespreking 3D-bestandsformaten................................................................................ 4

2.1.1

STL ....................................................................................................................... 7

2.1.2

PLY .................................................................................................................... 12

2.1.3

OBJ ..................................................................................................................... 14

2.1.4

OFF..................................................................................................................... 19

2.1.5

XYZ .................................................................................................................... 20

2.1.6

DXF .................................................................................................................... 21

2.1.7

VRML ................................................................................................................ 27

2.1.8

X3D .................................................................................................................... 37

2.1.9

GML en CityGML ............................................................................................. 39

2.2

Opbouw van de Java applicatie met behulp van NetBeans IDE ............................... 52

2.3

Testcases .................................................................................................................... 56

2.4

Overzicht van de software voor visualisatie van de resultaten .................................. 62

RESULTATEN ................................................................................................................ 63 3.1 Java-applicatie ................................................................................................................ 63 3.2 Bespreking testcases na conversie met Java-applicatie .................................................. 70 3.2.1 Case 1: DXF ............................................................................................................ 71 3.2.2 Case 2: OFF ............................................................................................................. 74 3.2.3 Case 3: CityGML .................................................................................................... 76 3.2.4 Case 4: OBJ ............................................................................................................. 77 ii

3.2.5 Case 5: STL ............................................................................................................. 78 3.2.6 Case 6: X3D (a) en X3DV (b) ................................................................................. 80 3.2.7 Case 7: PLY ............................................................................................................ 83 3.2.8 Case 8: VRML/WRL .............................................................................................. 85 3.2.9 Case 9: XYZ ............................................................................................................ 90 3.3 Algemene conclusie targetbestanden en softwareprogramma’s .................................... 90 4.

DISCUSSIE ...................................................................................................................... 99

5.

BESLUIT ....................................................................................................................... 102

6.

REFERENTIELIJST ...................................................................................................... 104 6.1 Literatuur ...................................................................................................................... 104 6.2 Internetbronnen ............................................................................................................ 107 6.3 Software ....................................................................................................................... 111

7.

BIJLAGEN ..................................................................................................................... 112 7.1 Java class bibliotheek citygml4j ................................................................................... 112 7.2 Volledige Java-applicatie ............................................................................................. 114

iii

LIJST VAN FIGUREN

Figuur 1: Voorstelling van ambient light, diffuse reflection en specular highlight ................. 10 Figuur 2: Scene-graph van het voorbeeld uit tabel 19 ............................................................. 29 Figuur 3: Resultaat na uitvoering van de VRML-code (tabel 20) in de Cortona3D Viewer ... 31 Figuur 4: Gebruik van texture mapping en belichting ............................................................. 36 Figuur 5: Overzicht mogelijke conversies in dit onderzoek .................................................... 53 Figuur 6: Opbouw van het algemeen datamodel in schemavorm ............................................ 54 Figuur 7: Visualisatie van de objecten uit case 1a en case 1b (DXF) met Autodesk Civil 3D 57 Figuur 8: Visualisatie van de kubus uit case 2 (OFF) met MeshLab ....................................... 58 Figuur 9: Visualisatie van het huis uit case 3 (CityGML) met FZK Viewer ........................... 58 Figuur 10: Visualisatie van de theepot uit case 4 (OBJ) met Autodesk 3ds Max .................... 59 Figuur 11: Visualisatie van de ster uit case 5 (STL) met MeshLab ......................................... 59 Figuur 12: Visualisatie van de vrouw uit case 6a (X3D) en case 6b (X3DV) met Cortona 3D Viewer...................................................................................................................... 60 Figuur 13: Visualisatie van straatverlichting uit case 7 (PLY) met CloudCompare ................ 60 Figuur 14: Visualisatie van het schip uit case 8 (VRML) met Cortona 3D Viewer ............... 61 Figuur 15: Visualisatie van de puntenwolk (kubus) uit case 9 (XYZ) met CCViewer ........... 61 Figuur 16: UML klassediagram van de Java-applicatie ........................................................... 64 Figuur 17: Snapshot van het batchbestand ............................................................................... 66 Figuur 18: Visuele voorstelling van de opsplitsing van een polygoon in driehoeken ............. 68 Figuur 19: Aanduiding 1e driehoek .......................................................................................... 68 Figuur 20: Aanduiding 2e driehoek .......................................................................................... 69 Figuur 21: Aanduiding 3e driehoek .......................................................................................... 69

iv

LIJST VAN TABELLEN

Tabel 1: Lijst met vooraf gedefinieerde entiteiten (XML) ......................................................... 5 Tabel 2: Fragment uit een XML-bestand ................................................................................... 6 Tabel 3: Algemene opbouw van een binair STL-bestand .......................................................... 8 Tabel 4: Algemene opbouw van een ASCII STL-bestand ......................................................... 9 Tabel 5: Algemene opbouw van een PLY-bestand .................................................................. 12 Tabel 6: Eenvoudig PLY-bestand ............................................................................................ 12 Tabel 7: Sleutelwoorden: vertex data ....................................................................................... 14 Tabel 8: Beschrijving van een eenvoudig veelvlak (OBJ-bestand) ......................................... 16 Tabel 9: Kubus met materiaaleigenschappen (OBJ-bestand)................................................... 16 Tabel 10: MTL-bestand met beschrijving van 3 materialen .................................................... 18 Tabel 11: Parameters voor de beschrijving van een kleur/materiaal in een MTL-bestand ...... 18 Tabel 12: Voorbeeld OFF-bestand ........................................................................................... 19 Tabel 13: Beschrijving van een rood (RGB: 255 0 0) vlak (OFF-bestand) ............................. 20 Tabel 14: XYZ-bestand ter illustratie....................................................................................... 21 Tabel 15: Beknopt overzicht van de codes naargelang hun datatype....................................... 22 Tabel 16: Eenvoudige DXF-filefragment (ASCII) .................................................................. 24 Tabel 17: Beschrijving van een eenvoudige lijn bestaande uit punt 1 (3.0, 5.0) en punt 2 (15.0, 20.0) (DXF-formaat / ASCII- versie) ...................................................................... 25 Tabel 18: Lijst met verschillende types tabellen ...................................................................... 27 Tabel 19: Opbouw van een VRML-bestand ............................................................................ 28 Tabel 20: VRML-file met meerdere shape nodes .................................................................... 30 Tabel 21: Gebruik van de IndexedFaceSet node ...................................................................... 32 Tabel 22: Overzicht geavanceerde nodes in VRML ................................................................ 32 Tabel 23: VRML transform node............................................................................................. 34 Tabel 24: DEF-syntax uit fragment VRML-code .................................................................... 35 Tabel 25: USE-syntax uit fragment VRML-code .................................................................... 35 Tabel 26: Beschrijving van twee vlakken in X3D-code (type .x3d) ........................................ 38 Tabel 27: Beschrijving van twee vlakken in X3D-code (type .x3dv) ...................................... 38 Tabel 28: Aanroep van het geometry XML-schema ................................................................ 40 Tabel 29: Basiselementen (type: geometry) ............................................................................. 41 Tabel 30: Eenvoudig GML-bestand ......................................................................................... 42 Tabel 31: LOD’s met hun toepassingsgebied en absolute nauwkeurigheid ............................. 44 v

Tabel 32: CityGML-bestand (gegenereerd met de Java class bibliotheek citygml4j) ............. 45 Tabel 33: CityGML modules met bijhorende XML-namespace identificatie en namespace prefix ........................................................................................................................ 50 Tabel 34: Opsomming XML-schema’s met bijhorende namespace identificatie en namespace prefix ........................................................................................................................ 51 Tabel 35: Data die in tabel 36 in het algemeen datamodel uitgeschreven zijn ........................ 55 Tabel 36: Uitgeschreven vorm van het algemeen datamodel .................................................. 56 Tabel 37: Overzicht testbestanden ........................................................................................... 56 Tabel 38: Overzicht software ................................................................................................... 62 Tabel 39: Methode public static void main uit de klasse converter ......................................... 65 Tabel 40: Trianguleer()-methode uit de klasse stl .................................................................... 67 Tabel 41: Uitwerking voorbeeld uit figuur 18 ......................................................................... 68 Tabel 42: Overzicht van softwareprogramma’s waarin men de DXF-sourcebestanden kan visualiseren (DXF uit case a en DXF2 uit case b) ................................................... 72 Tabel 43: Overzicht van softwareprogramma’s waarin men de targetbestanden kan visualiseren (case 1a) ............................................................................................... 72 Tabel 44: Overzicht van softwareprogramma’s waarin men de targetbestanden kan visualiseren (case 1b) ............................................................................................... 73 Tabel 45: Overzicht van softwareprogramma’s waarin men het OFF-sourcebestand kan visualiseren .............................................................................................................. 75 Tabel 46: Overzicht van softwareprogramma’s waarin men de targetbestanden kan visualiseren (case 2) ................................................................................................. 75 Tabel 47: Overzicht van softwareprogramma’s waarin men het CityGML-sourcebestand kan visualiseren .............................................................................................................. 76 Tabel 48: Overzicht van softwareprogramma’s waarin men de targetbestanden kan visualiseren (case 3) ................................................................................................. 76 Tabel 49: Overzicht van softwareprogramma’s waarin men het OBJ-sourcebestand kan visualiseren .............................................................................................................. 77 Tabel 50: Overzicht van softwareprogramma’s waarin men de targetbestanden kan visualiseren (case 4) ................................................................................................. 78 Tabel 51: Overzicht van softwareprogramma’s waarin men het STL-sourcebestand kan visualiseren .............................................................................................................. 79 Tabel 52: Overzicht van softwareprogramma’s waarin men de targetbestanden kan visualiseren (case 5) ................................................................................................. 79 vi

Tabel 53: Overzicht van softwareprogramma’s waarin men het X3D- en X3DVsourcebestand kan visualiseren ................................................................................ 81 Tabel 54: Overzicht van softwareprogramma’s waarin men de PLY-sourcebestanden kan visualiseren .............................................................................................................. 81 Tabel 55: Overzicht van softwareprogramma’s waarin men de targetbestanden kan visualiseren (case 6a) ............................................................................................... 82 Tabel 56: Overzicht van softwareprogramma’s waarin men de targetbestanden kan visualiseren (case 6b) ............................................................................................... 83 Tabel 57: Overzicht van softwareprogramma’s waarin men het PLY-sourcebestand kan visualiseren .............................................................................................................. 84 Tabel 58: Overzicht van softwareprogramma’s waarin men de targetbestanden kan visualiseren (case 7) ................................................................................................. 84 Tabel 59: Overzicht van softwareprogramma’s waarin men het VRML-sourcebestand kan visualiseren .............................................................................................................. 86 Tabel 60: Overzicht van softwareprogramma’s waarin men het OFF-sourcebestand kan visualiseren .............................................................................................................. 87 Tabel 61: Overzicht van softwareprogramma’s waarin men de targetbestanden kan visualiseren (case 8) ................................................................................................. 87 Tabel 62: Kleurinformatie VRML-bestand (fragment sourcebestand case8.vrml) ................. 88 Tabel 63: Kleurinformatie PLY-bestand (fragment PLY-bestand na omzetting in MeshLab) 89 Tabel 64: Overzicht van softwareprogramma’s waarin men het XYZ-sourcebestand kan visualiseren .............................................................................................................. 90 Tabel 65: Gemiddelde bestandsgrootte van de targetbestanden en beschrijving inhoud ........ 91 Tabel 66: Bestandsgrootte van de sourcebestanden ................................................................. 94 Tabel 67: Aantal failures bij het openen van de targetbestanden in de onderzochte softwareprogramma’s .............................................................................................. 95 Tabel 68: Overzicht percentage failures per formaat bij openen in software .......................... 97 Tabel 69: Java class bibliotheek citygml4j ............................................................................ 112

vii

1. INLEIDING

De mogelijkheid om de realiteit, toekomstige situaties of eenvoudige objecten in 3D voor te stellen is enorm populair. Virtual reality technieken worden steeds vaker toegepast bij het ontwerp en de uitvoering van (infrastructurele) werken maar ook voor besluitvorming, toeristische- en recreatieve doeleinden. De interactieve mogelijkheden van deze weergaves zorgen ervoor dat de gebruiker zich in deze virtuele wereld kan verplaatsen. Hierdoor kan men zich een beter en realistischer beeld vormen. De digitale 3D-weergave is een moderne visualisatietechniek die voorgaande technieken zoals maquettes en manuele 3D-tekeningen steeds meer op de achtergrond dringen. Bijgaande gepaarde ontwikkelingen voor data verzameling, -verwerking en -visualisatie kennen een enorme evolutie die zich steeds verder en verder ontplooit. Deze ontwikkelingen brengen met zich mee dat er alsmaar meer software op de markt voorhanden is en dat het aantal uitwisselings-/opslagformaten enorm toeneemt. Het kiezen van een geschikt bestandsformaat wordt voor de gebruiker steeds moeilijker. Bovendien

hangt

de

keuze

ook

af

van

het

beoogde

doel,

de

gewenste

weergaves/mogelijkheden en de software die de gebruiker voorhanden heeft. Vaak krijgt men bestanden aangereikt in een formaat waarvoor men geen geschikte software bezit. Enkele problemen steken hier al de kop op. Over welk formaat gaat het? Is het een tekstueel formaat? Zijn er vergelijkbare bestandsformaten die men wel kan openen en dezelfde inhoud bevatten? Is het mogelijk dit formaat te converteren? Gaat deze conversie gepaard met informatieverlies?

Het visualiseren van de 3D virtuele realiteit is enorm boeiend en biedt vele toekomstperspectieven. Toch zou er veel tijd uitgespaard kunnen worden indien men wist welk opslagformaat men het best gebruikt in combinatie met een welbepaalde viewer. In deze masterproef is onderzoek gedaan naar tien courant gebruikte bestandsformaten: DXF, CityGML, X3D/X3DV, VRML, OBJ, STL, OFF, PLY en XYZ. Deze worden elk afzonderlijk besproken. Om de formaten te onderzoeken en conversie mogelijk te maken is er een Java-applicatie ontwikkeld. Deze applicatie kan een bestandsformaat (uit de lijst van onderzochte formaten) inlezen, tijdelijk opslaan in een algemeen datamodel en tenslotte omzetten naar een ander formaat uit de lijst. Door het schrijven van de applicatie krijgt men een klaardere kijk op de inhoud en opbouw van het formaat. Het doel is om een overzicht te geven van de veel gebruikte bestandsformaten en een antwoord te formuleren op enkele vooropgestelde vragen. 1

In hoofdstuk 2 worden de materialen en methoden besproken uit dit onderzoek. Eerst is er een bespreking over de onderzochte formaten. Daarna volgt de uitleg over de opbouw van de Java-applicatie. Vervolgens krijgt u een overzicht van de testbestanden die men gebruikt heeft om de applicatie te testen en conclusies te formuleren. Tot slot kan u de lijst raadplegen van softwarepakketten die men in dit onderzoek heeft gebruikt. In dit hoofdstuk is getracht een antwoord te geven op een aantal vragen. In welk geval kiest men voor een bepaald formaat? Wat zijn de voor- en nadelen van de onderzochte formaten? Welke viewers zijn aangewend tijdens het onderzoek? Welke formaten zijn eenvoudig op te bouwen en te begrijpen?

In hoofdstuk 3 volgt de bespreking van de resultaten. Eerst wordt de opbouw van de Javaapplicatie nader toegelicht en worden de bijzonderheden uitgebreid besproken. Daarna worden de resultaten voor iedere testcase gepresenteerd. Dit hoofdstuk is afgesloten met een algemene conclusie wat betreft de targetbestanden en de softwareprogramma’s.

In hoofdstuk 4 worden de resultaten kritisch onder de loep genomen en is er getracht een terugkoppeling te maken naar de eerdere verrichte literatuurstudie. Deze vergelijking kan echter niet plaatsvinden omdat men in het literatuuronderzoek zich heeft toegelegd op dataverwerving (via laserscanning en topografische methodes) terwijl hier een onderzoek gevoerd is naar dataverwerking (bestandsformaten en softwareprogramma’s).

In hoofdstuk 5 is een besluit geformuleerd waarin de resultaten nogmaals kort en bondig zijn besproken.

In dit onderzoek is getracht om zo goed mogelijk te antwoorden op volgende onderzoeksvragen: 

Wat zijn de resultaten na conversie van de testbestanden?



Hoe presteren de softwarepakketten die gebruikt zijn in dit onderzoek?



Duiken er verschillen op in de prestaties van commerciële software ten opzichte van freeware?



Welk softwareprogramma komt het beste uit het onderzoek?



Welk bestandsformaat levert de meeste moeilijkheden / problemen?



Welk formaten bieden de meeste mogelijkheden aan qua beschrijving?

2



Is er een verband tussen de mogelijkheden van een bestandsformaat en de bestandsgrootte?



Is er verband tussen de mogelijkheden van een formaat en het aantal failures voor dat formaat?

Hier volgt een kort overzicht van de resultaten. Als eerste kan men besluiten dat de conversies via de Java-applicatie geslaagd zijn. De resultaten zijn in minstens 1 viewer te visualiseren en het desbetreffende object is identiek als vóór de conversie. De prestaties van de softwarepakketten zijn verschillend maar worden beïnvloed door het al dan niet ondersteunen van het DXF-formaat. Het onderzoek wees uit dat er geen noemenswaardig verschil is tussen het gebruik van commerciële software en freeware. Als men de resultaten van de werking van de software bekijkt is te merken dat in de top vijf slechts 1 commercieel programma te bespeuren is. Het is niet eenduidig welk programma het beste uit dit onderzoek komt aangezien er meerdere zijn die goed scoren. Indien men de werking vergelijkt met het aantal ondersteunende formaten dan komt MeshLab er als sterkste uit. Het staat buiten kijf dat DXF de meeste moeilijkheden teweegbrengt. Indien men slechts een eenvoudig object (geometrie) dient te beschrijven zonder meer dan zijn het OBJ- of het OFF-formaat de beste opties. Indien men meer mogelijkheden wenst dan maakt men best een keuze uit CityGML, VRML of X3D. Hoe meer mogelijkheden een bestandsformaat biedt, hoe groter de bestandsgrootte. Er is echter geen verband tussen die mogelijkheden en het aantal failures voor dat formaat.

3

2. METHODE EN MATERIALEN

2.1 Bespreking 3D-bestandsformaten

In dit onderdeel wordt voor ieder formaat afzonderlijk een overzicht gegeven betreffende de algemene kenmerken en opbouw van het formaat. Elk formaat wordt verduidelijkt aan de hand van een voorbeeld met extra informatie. Bij de bespreking van de formaten komt de term XML frequent voor. Eerst hierover een woord uitleg.

De Extensible Markup Language (XML) is een standaard aanbevolen door het Web3D Consortium voor onder andere de beschrijving van gestructureerde data en de opslag ervan. De ontwikkeling van XML startte in 1996. XML zorgt ervoor dat gegevens gemakkelijk uit te wisselen zijn via een flexibel formaat en dit onafhankelijk van andere applicaties, platformen en programmeertalen. Bovendien is het een generieke markuptaal omdat ze een document van tags kan voorzien om de data te structureren. Bij XML ligt de nadruk dus op de structuur van de informatie. Deze structuur kan men op twee manieren definiëren: via een DTD (Document Type Definition) of via de XML Schema Language. Deze schema’s specifiëren de tags die men kan gebruiken in het XML document. Daarnaast leggen ze ook vast wat de inhoud en de attributen van die tags mogen zijn (Goldberg, 2009).

In een XML-document kunnen vier onderdelen voorkomen: elementen (elements), attributen (attributes), inhoud (content) en entiteiten (entities). De tags kunnen onderverdeeld worden in een starten eindtag. Een XML-element is alles wat zich tussen de starten eindtag bevindt. Elementen kunnen dus andere elementen bevatten, maar ook tekst en attributen. Soms is er ook sprake van een lege tag. Dit komt voor wanneer er niets staat tussen de starten eindtag. Een voorbeeld zal bovenstaande uitleg verduidelijken: 200, waarbij ‘’ de starttag is, ‘’ de eindtag en ‘200’ het element. XML-elementen kunnen ook attributen bevatten die bijkomende informatie geven over het element. Het attribuut bestaat uit een sleutel (key) en een waarde (value) die van elkaar gescheiden worden door een ‘=’ teken. Een voorbeeld ter verduidelijking: <Wegsegment type = “snelweg”>, waarbij ‘type’ de sleutel is en ‘snelweg’ de waarde. De waardes van het attribuut moeten altijd tussen aanhalingstekens staat. Men mag kiezen tussen twee notaties: ‘waarde’ of “waarde”. Men kan zich afvragen wat het verschil is tussen attributen en elementen. Hierop is het antwoord dat er geen verschil is en dat beiden dezelfde informatie meegeven. Men is vrij 4

om te kiezen wat men gebruikt. Tot slot kunnen er ook entiteiten opduiken in het XMLdocument. Dit zijn tekens die een speciale betekenis hebben en niet zomaar kunnen voorkomen in de inhoud van een element, de namen van attributen en elementen of in de value van een attribuut. Omwille hiervan bestaan er escape facilities. Dit wil zeggen dat deze tekens toch kunnen gebruikt worden in de inhoud van een element of in de value van attributen door het gebruik van een overeenkomstige code. In tabel 1 is de lijst met entiteiten weergegeven evenals hun escape facilities (http://www.w3.org, 10 juli 2013).

Tabel 1: Lijst met vooraf gedefinieerde entiteiten (XML) Bron: http://www.w3.org, 10 juli 2013 Entiteit

Beschrijving

Escape facilities

&

ampersand

&

<

kleiner dan teken

<

>

groter dan teken

>

‘

apostrof

&apos

“

quote

"

Een XML-bestand heeft een hiërarchische structuur. Het is een boomstructuur waarbij een onderscheid gemaakt wordt tussen child-elements en parent-elements. Met uitzondering van het root-element1 heeft elk element een parent (http://www.w3.org, 10 juli 2013). Typisch voor het XML-formaat is het gebruik van tags die niet gedefinieerd zijn in de XML-standaard. De auteur kan dus zelf tags aanmaken maar moet die dan ook definiëren door het bijvoegen van een XSL2 file. Indien de auteur hieraan verzaakt kan de browser of eender welke XMLreader het bestand niet interpreteren aangezien de tags nergens beschreven staan (Amiano et al., 2006; Goldberg, 2009).

Het opstellen van een XML-bestand is vrij eenvoudig als men enkele regels in acht neemt. In tabel 2 wordt een fragment uit een XML-bestand weergegeven. Volgende regels moeten nageleefd worden (Amiano et al., 2006; Goldberg, 2009; http://www.w3.org, 10 juli 2013):

1

Ieder XML-document moet één element hebben dat alle andere elementen omvat. Dit element noemt men het root-element. 2 eXtensible Stylesheet Language.

5



bovenaan het document moet een XML-header gedefinieerd worden om aan te tonen dat het om een XML-document gaat: “”;



er moet een uniek root-element aanwezig zijn;



elke begintag sluit men af met een eindtag of indien er geen inhoud is, sluit men de begintag af met een slash (/);



de elementen moeten correct genest zijn, dit wil zeggen dat men het laatste element in de boomstructuur eerst moet afsluiten;



de value moet altijd tussen quotes staan;



indien de gebruiker commentaarregels wenst in te voeren dan moet de commentaar staan tussen ;



de elementnamen zijn hoofdlettergevoelig. Wanneer het element van de begintag met een hoofdletter is geschreven en het element van de eindtag met een kleine letter (en omgekeerd) dan zal het bestand niet correct kunnen uitgevoerd worden;



entiteiten kan men niet zomaar overal gebruiken maar indien nodig spreekt de gebruiker de escape facilities aan.

Tabel 2: Fragment uit een XML-bestand Bron: eigen verwerking <note> Gebruiker Sarah Eenvoudig voorbeeld Op deze wijze wordt het XML-bestand opgebouwd.

Kiezen voor een opslag in een XML-formaat biedt vele voordelen (Goldberg, 2009): 

XML is een metataal;



XML is gemakkelijk te interpreteren door mens en computer;



XML is een gestructureerde taal. Dit houdt in dat men exact kan beschrijven hoe de gegevens georganiseerd, gerangschikt en uitgedrukt moeten worden. Het is zelfs mogelijk om te valideren of het XML-bestand aan een specifieke structuur voldoet, alvorens de gegevens ingelezen worden;



XML is een wereldwijde standaard. 6

De waarde van een XML-document is dus gebaseerd op drie belangrijke eigenschappen: structureerbaarheid (flexibel formaat), valideerbaarheid en uitbreidbaarheid. Het is ideaal bij de uitwisseling van documenten tussen organisaties of tussen samenwerkende systemen (Goldberg, 2009).

2.1.1 STL

Stereo Lithography of kortweg STL is een bestandsformaat dat in functie van de stereolithografie3 gecreëerd is door de Albert Consulting Group voor 3D Systems Inc4. Het formaat wordt vaak gebruikt bij Selective Laser Sintering5, Laminated Object Manufacturing6 en 3D-printing (Szilvśi-Nagy & Mátyási, 2003). STL wordt ook afgekort als Standard Tessellation Language en wordt ondersteund door vele softwarepakketten zoals 3ds Max, Adobe 3D Reviewer en Wings 3D (McHenry & Bajcsy, 2008). De populariteit van dit formaat werkt de ontwikkeling van allerlei conversiesoftware in de hand, om op die manier allerlei standaard inputformaten te converteren naar STL (Ho-chan et al., 2002).

STL-bestanden beschrijven enkel de geometrie van een driedimensionaal object. Dit houdt in dat er geen extra informatie zoals kleur, textuur of topologische informatie (proximiteit en verwijzingen) kan worden meegegeven. Het object wordt beschreven aan de hand van driehoekige vlakken die in het bestand zijn gedefinieerd. Elke driehoek is beschreven door middel van zijn normaalvector (facet normal7) en de bijhorende geordende8 hoekpunten (Szilvśi-Nagy & Mátyási, 2003). De STL-bestanden kan men opdelen naargelang hun opslagformaat. Er bestaat zowel een ASCII- als een binair formaat. In de meeste gevallen verkiest men het binaire formaat aangezien de grootte slechts ¼ bedraagt van een ASCII STL-

3

Stereolithografie is een rapid prototyping vormgeefproces. Via dit proces is het mogelijk om vertrekkende van een CAD file rechtstreeks modellen te maken uit kunststof. Laagsgewijs wordt uit een vloeistof een object gemaakt (http://enacoc.epfl.ch/files, 20 februari 2013). 4 Amerikaans bedrijf dat zich gespecialiseerd heeft in 3D printers en 3D modellering (http://www.3dsystems.com, 20 februari 2013). 5 Dit is een rapid prototyping techniek waarbij gebruik gemaakt wordt van het sinterproces. Het virtueel CADmodel wordt in lagen opgedeeld en deze lagen worden één voor één met een laser gesinterd (http://enacoc.epfl.ch/files, 20 februari 2013). 6 Dit is een Rapid prototyping techniek waarbij dunne lagen opeenvolgend op elkaar gelamineerd worden (http://enacoc.epfl.ch/files, 20 februari 2013). 7 De vector die loodrecht staat op elke polygoon in een mesh-oppervlak (http://www.visualization.hpc.mil, 2 maart 2013). 8 De hoekpunten worden in het bestand geordend ten opzichte van de normaalvector in tegenwijzerszin (Ho-chan et al., 2002).

7

bestand (Ho-chan et al., 2002). Een uitbreiding op het STL-formaat is het SLP-formaat welke een RGB kleur kan toekennen aan elke driehoek (Wu & Cheung, 2006).

Tabel 3: Algemene opbouw van een binair STL-bestand Bron: eigen verwerking UINT8[80] UINT32

header; geheel getal dat het aantal driehoekige vlakken in het binaire STL-bestand vermeldt;

voor elke driehoek worden onderstaande gegevens bijgehouden; REAL32[3] REAL32[3] REAL32[3] REAL32[3] UINT16 end

normaal vector; hoekpunt 1; hoekpunt 2; hoekpunt 3; attribute byte count; einde bestand;

De header in de bovenstaande code kan maximaal 80 karakters bevatten en is een 8 bit integer. Bovendien kan de header enkel positieve waarden bevatten aangezien het gaat om een UINT (unsigned integer). Vervolgens wordt in de code een 32 bit unsigned integer (UINT) bijgehouden die het aantal driehoekige vlakken vermeldt die opgenomen zijn in het bestand. Daarna volgt voor elk driehoekig vlak een beschrijving van zijn gegevens. De normaalvector en de hoekpunten van het vlak worden beschreven door een REAL32. Dit is een IEEE 7549 getal met zwevende komma10 die exact 32 bits gebruikt bij zijn presentatie. Voor de normaalvector en de hoekpunten van ieder afzonderlijk vlak worden dus drie getallen opgeslagen van het type REAL32, zijnde de x-,y- en z-coördinaat. Dit is het geval voor zowel de binaire als voor de ASCII- versie (Murdocca & Heuring, 2000; Iancu et al., 2010; http://verse.blender.org/fileadmin, 28 februari 2013).

9

De IEEE 754 standaard beschrijft hoe getallen met een zwevende komma kunnen voorgesteld worden in het geheugen van een binaire machine. Dit moet gebeuren op een snelle en efficiënte manier. Er bestaan twee formaten bij deze standaard: deze met de enkele precisie (32-bit getal) en daarnaast die met de dubbele precisie (64-bit getal) (Murdocca & Heuring, 2000). 10 Een zwevend kommagetal of drijvend kommagetal (floating point) is een gegevenstype dat een vaste geheugenruimte beslaat. Het is een methode om getallen met cijfers na de komma op een andere manier te noteren. Het voordeel hiervan is dat met een beperkt aantal bits een enorm groot bereik van getallen kan worden bestreken (Murdocca & Heuring, 2000).

8

Tabel 4: Algemene opbouw van een ASCII STL-bestand Bron: eigen verwerking solid naam_object

facet normal NxNyNz outer loop vertex X1Y1Z1 vertex X2Y2Z2 vertex X3Y3Z3 endloop endfacet

... endsolid

identificeert het ASCIIbestand waar ‘naam_object’ optioneel is; het bestand start met een bepaald aantal driehoeken die elk afzonderlijk worden gedefinieerd; NxNyNz : de coördinaten van de normaalvector; X1Y1Z1, X2Y2Z2 en X3Y3Z3 geven de coördinaten van de drie hoekpunten van het vlak weer; einde van de beschrijving van een bepaalde driehoek. Indien nog niet alle vlakken bepaald zijn herhaalt dit stukje code zich tot alle vlakken beschreven zijn; deze coderegel sluit het bestand af;

Iancu et al. (2010) beschrijven twee manieren om kleurinformatie toch op te nemen in het STL-bestand. Aangezien de kleur niet rechtstreeks wordt opgenomen maakt men gebruik van de softwarepakketten VisCAM en SolidView. Deze software kent een 1511 bit RGB kleur toe aan de attribute byte count op het einde van alle driehoekgegevens. Bij de tweede manier werkt men met het softwarepakket Materialise Magics. Dit pakket zal in de header van het bestand een kleur toekennen. Dit gebeurt met een ASCII string ‘COLOR=’ gevolgd door vier bytes die de kleur voorstellen. De bytes bevatten een waarde voor rood, groen en blauw (RGB kleur) maar ook een alfakanaal dat de transparantiegraad bepaalt. De toekenning van deze kleur geldt voor het volledige object tenzij deze kleur overschreven wordt door gebruik te maken van één van bovenstaande softwarepakketen. Magics biedt de mogelijkheid om naast kleur ook een materiaalspecificatie toe te kennen. Na de kleurbeschrijving volgt dan een andere ASCII string ‘MATERIAL=’ gevolgd door drie kleurwaarden (dus drie maal 4 bytes). De eerste kleur wordt gebruikt voor de diffuse reflection12, de tweede voor specular

11

Dit is de toekenning van een high color. Een high color bestaat uit 15 bits, dit wil zeggen dat er 1 bit van de 2 bytes genegeerd wordt of eventueel gebruikt is als waarde voor een alfakanaal. De 15 bits zijn opgesplitst tussen rood, groen en blauw. 12 Diffuse reflectie ontstaat wanneer een straal invalt op een oppervlak en teruggekaatst wordt onder vele verschillende hoeken. Door deze terugkaatsing van het licht wordt het object zichtbaar voor de waarnemer (McConnell, 2006, p. 71).

9

highlight13 en de derde is een waarde voor ambient light14. Samen vormen ze een bepaalde materiaaleigenschap die men bij de visualisatie kan toekennen.

Figuur 1: Voorstelling van ambient light, diffuse reflection en specular highlight Bron: Bateman & Olsson, 2010, p. 101

Een grote contra bij het gebruik van STL-formaten is de grote opslagcapaciteit. Dit komt omdat de gegevens steeds herhaald worden aangezien er geen topologische relaties aanwezig zijn. De verwerking van de STL-bestanden verloopt hierdoor aanzienlijk trager. Dit is in tegenstelling met het PLY-formaat (2.1.2) waar de coördinaten slechts eenmaal worden opgeslagen en de opbouw van de vlakken gebeurt door middel van een verwijzing (Angeles et al., 2010). Een tweede nadeel duikt op bij de conversie van CAD bestanden naar STL. Door de omzetting kunnen fouten ontstaan in het bestand. Hierdoor zullen bewerkingen zoals object-oriëntatie of het snijden van objecten onregelmatigheden vertonen in het uiteindelijke resultaat. De meest voorkomende fout is de ‘hole error’ en ontstaat door het niet aaneensluiten van driehoeken of het ontbreken van een driehoekig vlak. De ‘overlapping error’ ontstaat waar de driehoekige vlakken elkaar overlappen en dus over elkaar heen liggen. Tenslotte komt soms ook de ‘normal vector error’ voor. Dit wil zeggen dat in het bestand de richting van de normale omgekeerd is waardoor de oriëntatie foutief is (Ho-chan et al., 2002; Iancu et al., 2010).

In zowel de binaire als de ASCII- versie is de normaalvector een eenheidsvector die zich ten opzichte van het object naar buiten richt. Meestal krijgt deze normale zowel voor de x-, y- en z-coördinaat de waarde nul mee van de software. Het eigenlijke softwarepakket zal automatisch de correcte waarden bepalen voor de normale aan de hand van de coördinaten 13

Specular highlight is de heldere vlek die men waarneemt op een voorwerp dat belicht wordt. Men mag dit niet verwarren met de diffuse reflectie. Het verschil is dat men bij specular hightlight enkel een lichtvlek ziet op het object terwijl de diffuse reflectie ervoor zorgt dat het voorwerp in zijn geheel zichtbaar is (Lanier, 2008, pp. 4-5). 14 Ambient light (sfeerlicht) is een lichtbron met welbepaalde intensiteit en kleur die alle objecten in die omgeving op eenzelfde manier beïnvloed (Bateman & Olsson, 2010, pp. 100-101).

10

van de hoekpunten van het vlak. In sommige gevallen worden in het STL-bestand direct de waarden van de coördinaten van de normale meegegeven. De meeste softwarepakketten controleren bij het inladen van het bestand deze waarden. Dit houdt in dat de coördinaten van de normale berekend en vergeleken worden met deze in het oorspronkelijke STL-bestand. Indien de berekende waarden verschillend zijn van de opgegeven waarden, zal de software een waarschuwing tonen aan de gebruiker. Deze is dan genoodzaakt om de waarden van de normale te corrigeren of ze allemaal gelijk te stellen aan nul (zoals hierboven is besproken). Indien de gebruiker hieraan verzaakt zal het uiteindelijke resultaat niet correct zijn. Er dient wel opgemerkt te worden dat sommige softwarepakketten deze controle bij het inladen van het STL-bestand niet uitvoeren. Het spreekt voor zich dat dit soms leidt tot foute resultaten aangezien de gebruiker zich van geen kwaad bewust is. Het is daarom aangeraden om de coördinaten, bij het invoeren van het bestand, gelijk te stellen aan nul. De software houdt hier immers rekening mee en zal op zijn beurt de juiste coördinaten berekenen (Ho-chan et al., 2002; Iancu et al., 2010).

Het gebruik van het STL-formaat is niet altijd een goede keuze, ondanks het feit dat achter het formaat een vrij eenvoudige en gemakkelijke code verscholen zit. Het STL-formaat biedt de mogelijkheid om een willekeurige polygoon/ 3D-object te beschrijven maar deze moeten opgebouwd worden uit afzonderlijke driehoeken. Dit komt doordat het formaat enkel driehoeken kan beschrijven. Dit zal dus ook problemen genereren wanneer men het bestand zal willen converteren (Iancu et al.,2010). Volgens Iancu et al. (2010) kan het STL-formaat aanzienlijk verbeterd worden. Zo zou het opmaken van een lijst met alle hoekpunten in plaats van een individuele opsomming per driehoek een grote verbetering zijn. Hierdoor zou elk punt maar eenmalig beschreven worden en de bestandsgrootte verminderen. Ondanks de vele mogelijkheden voor verandering, aanpassing en uitbreiding van het formaat zijn nog maar weinig veranderingen doorgevoerd. De gemakkelijke verstaanbaarheid en de eenvoudige syntax van de code blijven de sleutel tot succes. Het uiteindelijk doel is om de realiteit zo goed mogelijk te benaderen maar laat hier duidelijk zijn dat dit net het zwakke punt is van het STL-bestandsformaat (Iancu et al., 2010).

11

2.1.2 PLY

PLY, beter gekend onder de naam Stanford Triangle Format of Polygon File Format, is een bestandsformaat waarin men 3D-data opslaat. Voor deze opslag kan men kiezen tussen een ASCII- of een binaire codering. PLY-bestanden zijn platformonafhankelijk en kunnen data bevatten van vertexen en vlakken. Extra informatie zoals kleur, loodlijnen en specifieke eigenschappen kan men eveneens opnemen. Het eenvoudige en flexibele karakter van het PLY-bestand zorgt ervoor dat het formaat populair is in de academische – en onderzoekswereld (McHenry & Bajcsy, 2008). Tabel 5 toont de algemene opbouw van een PLY-bestand in ASCII- codering. In tabel 6 is een voorbeeldcode uitgewerkt ter verduidelijking.

Tabel 5: Algemene opbouw van een PLY-bestand Bron: eigen verwerking ply format comment <eventuele commentaar> element property <eigenschap naam 1> property <eigenschap naam 2> property <eigenschap naam 3> ... end_header (hieronder volgen de data)

Tabel 6: Eenvoudig PLY-bestand Bron: eigen verwerking ply format ascii 1.0 comment aangemaakt door Sarah comment creatie kubus element vertex 8 property float x property float y property float z element face 6 property list uchar vertex_indices

start header; definieert dataformaat en versie; commentaar kan geschreven worden na ‘comment’; toont aan dat er 8 vertex elementen zijn in de file; hierop volgen de eigenschappen (properties) voor het opgegeven element; toont aan dat er 6 ‘faces’ in bestand vervat zijn;

12

end_header 000 001 011 010 100 101 111 110 40123 47654 40451 41562 42673 43740

hier start de vertex data. De eerste lijn bevat de data voor het eerste punt, de tweede lijn data voor het tweede punt enz…;

hier start de ‘face’ data. Hetzelfde principe als voor de vertex data. Eerst wordt een integer beschreven die aangeeft hoeveel punten het vlak bevat. Hier worden er allemaal vlakken met 4 hoeken beschreven. Daarna volgt de opsomming van de punten (afkomstig van de vertex data);

Een PLY-bestand bestaat uit verschillende onderdelen. De eerste lijn moet het woord ‘PLY’ bevatten en is de start van de header. De volgende regel beschrijft het dataformaat en de versie. Eventuele commentaar kan men overal in het tekstbestand invoegen achter het woord ‘comment’. De header bevat verder ook informatie over de uiteindelijke data. Zo zal men moeten opgeven hoeveel punten de dataset bevat en hoeveel vlakken er gevormd worden. Dit wordt opgegeven na het woord ‘element’. Na elke element-regel volgen de properties voor dat element. De header beëindigt men met de woorden ‘end_header’. Na de header volgen alle data (vertexlist en facelist) (Mukundan, 2012).

Het voorbeeld in tabel 6 kan men uitbreiden met extra informatie zoals kleur. Dit is mogelijk door bij de eigenschappen van een bepaald element enkele coderegels in te voegen. Bij de vertex elementen moet men volgende regels invoegen: property red uchar, property green uchar en property blue uchar. Indien men dit wenst kan men ook een transparantiegraad invoegen (property alpha uchar) of werken met materiaaldefinities (property material_index int). Daarnaast is het eveneens mogelijk om aan de vlakken kleuren toe te kennen. Dit gebeurt op dezelfde wijze maar dan na de definiëring van het onderdeel faces. Bij de data van het desbetreffende element kunnen dan de RGB waarden worden opgeven. Dit gebeurt telkens op dezelfde regel na de benoeming van de data. Andere informatie kan op een zelfde wijze worden toegevoegd. Voor de meeste toepassingen zal men gebruik maken van punten (vertexes) en vlakken (faces) om objecten te kunnen creëren. Soms verkiest de gebruiker om te werken met puntenwolken en dan zullen de vlakken-data achterwege blijven (http://www.cs.virginia.edu, 7 februari 2013). 13

Wanneer men dit formaat wenst te gebruiken voor de creatie van een volledige 3D-wereld dan moet de gebruiker weten dat er slechts één object per PLY-bestand kan gedefinieerd worden. Voor beschrijving van een 3D scene zullen dus meerdere PLY files gemaakt en geïmplementeerd moeten worden.

2.1.3 OBJ

OBJ is een open standaard dataformaat voor de opslag en uitwisseling van 3D gegevens en ontworpen door Wavefront Technologies. Wavefront Object Files kan men gebruiken om geometrische objecten, samengesteld uit lijnen, polygonen, curves en objecten op te slaan. Het bestandsformaat kan een object zowel als een ASCII- (.obj) of binair (.mod) bestand beschrijven. Het binaire formaat is echter eigendom van Wavefront Technologies en nergens beschreven. Omwille hiervan wordt enkel verder ingegaan op de ASCII-versie (Murray et al., 1996; Rideout, 2010).

Het OBJ-bestand is niet voorzien van een header maar het bestand wordt vaak gestart met een verduidelijkende commentaarlijn. Commentaarregels beginnen steeds met een hekje (#). Het is mogelijk om lege regels te creëren zodat het bestand overzichtelijk en gemakkelijk leesbaar blijft. Alle andere regels beginnen met een sleutelwoord, gevolgd door de data die daarbij horen. Wanneer deze data meerdere regels beslaan dan moet men deze regels aan elkaar koppelen door middel van een backslash teken (\) op het einde van elke regel. In tabel 7 volgt een beknopt overzicht van de belangrijkste sleutelwoorden en bijhorende data die kunnen opgenomen worden (Murray et al., 1996; Rideout, 2010; Patnaik et al., 2012; http://lesmodules.lamp.tudelft.nl, 16 april 2013).

Tabel 7: Sleutelwoorden: vertex data Bron: naar Murray et al., 1996 Beschrijving

Sleutelwoord

2D curve

2D curv

Basis matrix

bmat

Belichting

trace_obj

Connectiviteit tussen twee objecten

con

Curve

curv

14

Einde statement

end

Geometrisch punt

v

Graden

deg

Inner trimming loop

hole

Kleur interpolatie

c_interp

Level of detail

lod

Lijn

l

Materiaal bibliotheek

mtllib

Materiaal naam

usemtl

Naam groep

g

Normale

vn

Objectnaam

o

Oppervlak

surf

Outer trimming loop

trim

Punt

p

Schaduw

shadow_obj

Textuur punt

vt

Type oppervlak of curve

cstype

Vlak

f

De meeste OBJ-bestanden definiëren vooral punten, vlakken en kennen uiterlijke eigenschappen toe. In tabel 8 wordt een vlak beschreven bij wijze van voorbeeld. Iedere lijn die start met het sleutelwoord ‘v’ bevat de beschrijving van een punt. Na het sleutelwoord volgt de x-,y- en z-waarde. De vlakken worden gecreëerd na de opsomming van de punten. De lijnen die beginnen met het sleutelwoord ‘f’ vormen de vlakkenlijst. Per vlak wordt een opsomming gegeven van indices die de punten uit de puntenlijst vertegenwoordigen. Het voorbeeld in tabel 8 is vrij eenvoudig aangezien het bestand slechts drie punten en een vlak beschrijft. In tegenstelling tot sommige andere formaten heeft het eerste punt in de puntenlijst index 1 (in plaats van 0) (Patnaik et al., 2012).

15

Tabel 8: Beschrijving van een eenvoudig veelvlak (OBJ-bestand) Bron: eigen verwerking # veelvlak

commentaar;

v 0.0 0.0 0.0 v 0.0 1.0 0.0 v 1.0 0.0 0.0

start van de puntenlijst;

f123

start van de vlakkenlijst (hier slechts 1 vlak);

OBJ-files kunnen op verschillende manieren kleurdefinities bevatten. De eerste en eenvoudigste optie is het toekennen van een RGB waarde aan elke ‘v’-regel. Een tweede optie is het verwijzen naar een materiaalbibliotheek dat zich in een aparte MTL (Material Library File) -file bevindt. Deze file kan opgeroepen worden in het OBJ-bestand door vermelding van het sleutelwoord ‘mtllib’. De materiaalbibliotheek kent aan een vlak een bepaalde kleur of materiaaltextuur toe. De materialen worden in het MTL bestand gedefinieerd door enkele parameters (RGB waarden, transparantiegraad, schaduweffect,…) en kunnen in het OBJbestand gebruikt worden door het sleutelwoord ‘usemtl’ te gebruiken gevolgd door de naam van het gedefinieerde materiaal. Alle vlakken die volgen na het ‘usemtl’ sleutelwoord worden weergegeven in het gedefinieerde materiaal. Vlakken en objecten kunnen ingedeeld worden in groepen met behulp van het sleutelwoord ‘g’. Hierdoor worden sub-objecten gecreëerd. Dit zorgt voor een overzichtelijke codering met de mogelijkheid om achteraf gemakkelijk aanpassingen te doen. In tabel 9 wordt een kubus beschreven waarbij aan de vlakken verschillende materialen zijn toegekend (Murray et al., 1996; Rideout, 2010; Patnaik et al., 2012).

Tabel 9: Kubus met materiaaleigenschappen (OBJ-bestand) Bron: eigen verwerking # Kubus met toekenning van verschillende materialen mtllib master.mtl

verwijzing naar extern materiaalbibliotheek;

v 0.000000 2.000000 2.000000 v 0.000000 0.000000 2.000000 v 2.000000 0.000000 2.000000

start puntenlijst;

bestand

met

16

v 2.000000 2.000000 2.000000 v 0.000000 2.000000 0.000000 v 0.000000 0.000000 0.000000 v 2.000000 0.000000 0.000000 v 2.000000 2.000000 0.000000 g front usemtl red f1234

definiëring van een groep genaamd ‘front’; toekenning van de materiaaleigenschap ‘red’; (gedefinieerd in de externe file) + definiëring van een vlak met de punten 1,2,3 en 4 uit de puntenlijst;

g back usemtl blue f8765

definiëring van een groep genaamd ‘back’; toekenning van de materiaaleigenschap ‘blue’; (gedefinieerd in de externe file) + definiëring van een vlak met de punten 8,7,6 en 5 uit de puntenlijst;

g right usemtl green f4378

definiëring van een groep genaamd ‘right’; toekenning van de materiaaleigenschap ‘green’; (gedefinieerd in de externe file) + definiëring van een vlak met de punten 4, 3, 7 en 8 uit de puntenlijst;

g top usemtl gold f5148

definiëring van een groep genaamd ‘top’; toekenning van de materiaaleigenschap ‘gold’; (gedefinieerd in de externe file) + definiëring van een vlak met de punten 5, 1, 4 en 8 uit de puntenlijst;

g left usemtl orange f5621

definiëring van een groep genaamd ‘left’; toekenning van materiaaleigenschap ‘orange’; (gedefinieerd in de externe file) + definiëring van een vlak met de punten 5, 6, 2 en 1 uit de puntenlijst;

g bottom usemtl purple f2673

definiëring van een groep genaamd ‘bottom’; toekenning van de materiaaleigenschap ‘purple’; (gedefinieerd in de externe file) + definiëring van een vlak met de punten 2, 6, 7 en 3 uit de puntenlijst;

In tabel 10 is een voorbeeld MTL-bestand te zien. In het bestand kunnen meerdere kleuren of materialen beschreven worden aan de hand van verschillende parameters (tabel 11).

17

Tabel 10: MTL-bestand met beschrijving van 3 materialen Bron: eigen verwerking # bestandsnaam: ‘materialen’

commentaar;

newmtl wit Ka 0.6 0.6 0.6 Kd 1.0 0.7 0.5 illum 1

materiaaldefiniëring met verwijsnaam ‘wit’; definiëring van de ‘ambient’ kleur; definiëring van de ‘diffuse’ kleur; geen ‘specular’ kleur gedefinieerd ;

newmtl rood Ka 0.2 0.0 0.0 Kd 0.5 0.0 0.0 Ks 0.6 0.2 0.2 illum 2 Ns 100.0

materiaaldefiniëring met verwijsnaam ‘rood’; definiëring van de ‘ambient’ kleur; definiëring van de ‘diffuse’ kleur; definiëring van de ‘specular’ kleur; aanwezigheid ‘specular’ kleur; maat voor de glans;

newmtl blauw Ka 0.1 0.1 0.4 Kd 0.1 0.1 0.9 illum 1 Tr 0.55

materiaaldefiniëring met verwijsnaam ‘blauw’; definiëring van de ‘ambient’ kleur; definiëring van de ‘diffuse’ kleur; geen ‘specular’ kleur gedefinieerd; transparantiegraad;

Tabel 11: Parameters voor de beschrijving van een kleur/materiaal in een MTL-bestand Bron: http://lesmodules.lamp.tudelft.nl, 16 april 2013 Beschrijving

Sleutelwoord

Ambient15 kleur

Ka (gevolgd door een RGB waarde)

Diffuse16 kleur

Kd (gevolgd door een RGB waarde)

Specular17 kleur

Ks (gevolgd door een RGB waarde)

Transparantiegraad

d of Tr (indien niet gedefinieerd is dit standaard 1)

Maat voor de glans van een object

Ns (indien niet gedefinieerd is dit standaard 0)

Belichtingsmodel van het materiaal

illum (waarde 1= geen specular kleur; waarde 2 = aanwezigheid van specular kleur

15

Dit is de kleur van een object dat zich in de schaduw bevindt (figuur 1) (http://docs.autodesk.com, 16 april 2013) 16 Dit is de kleur die een object reflecteert of anders gezegd de kleur dat het object heeft als er licht op invalt (figuur 1) (http://docs.autodesk.com, 16 april 2013). 17 Dit is de kleur van de highlights op een glanzend oppervlak (figuur 1) (http://docs.autodesk.com, 16 april 2013)

18

dus moet Ks gedefinieerd worden) Verwijzing naar een bitmap bestand18 (voor Map_KA (gevolgd door de bestandsnaam) het invoegen van een textuur)

2.1.4 OFF

Het Object File Format bestaat al geruime tijd en wordt gebruikt voor de opslag en uitwisseling van 3D-objecten. Het formaat bestaat uit een ASCII-versie en heeft een eenvoudige opbouw. De mogelijkheden van het formaat zijn vrij beperkt maar desondanks wordt dit formaat vaak gebruikt (Mukundan, 2012).

Tabel 12: Voorbeeld OFF-bestand Bron: eigen verwerking OFF # Beschrijving van een vlak 412 0.0 0.0 0.0 0.0 12.0 0.0 6.0 12.0 0.0 6.0 0.0 0.0 40123

header; commentaarregel; aantal punten – aantal vlakken – aantal randen; start puntenlijst;

einde puntenlijst; start vlakkenlijst (hier maar 1 vlak);

Een OFF-bestand bestaat steeds uit een header die ervoor zorgt dat het bestand herkend wordt als een OFF-bestand. Alle regels die beginnen met het hekje (#) kan men beschouwen als commentaarregels. De commentaar heeft geen vaste plaats en mag eender waar voorkomen in het document. In het voorbeeld (tabel 12) staat deze regel onder de header. Alvorens de punten en de vlakken te declareren dient men een regel in te voeren waarin 3 getallen staan. Het eerste getal geeft aan de gebruiker mee hoeveel punten er in het bestandje aanwezig zijn. Het volgende getal staat voor het aantal vlakken en tot slot is er nog een derde getal dat het aantal randen in het object meegeeft. Na deze regel wordt de puntenlijst en vlakkenlijst beschreven. Het definiëren van een vlak gebeurt steeds door eerst het aantal hoekpunten van het desbetreffende vlak te vermelden. Daarna volgt, op dezelfde regel, de verwijzing naar de index van de punten uit de vlakkenlijst. Het is belangrijk om te vermelden dat de index start 18

Dit bestandje moet met het MTL-bestand in een gezamenlijke map zitten (http://lesmodules.lamp.tudelft.nl, 16 april 2013).

19

bij 0 en niet bij 1. In het voorbeeld wordt een vlak beschreven met punt 0, 1, 2 en 3. Indien dit gewenst is kunnen de vlakken van een kleur voorzien worden. Dit gebeurt door toekenning van RGB of RGBA waarden. Deze waarden kunnen weergegeven worden door gehele getallen (0-255) of door kommagetallen (0-1). De toekenning van een kleur aan een vlak gebeurt op dezelfde lijn na de definitie van dat vlak (tabel 13) (Mukundan, 2012).

Tabel 13: Beschrijving van een rood (RGB: 255 0 0) vlak (OFF-bestand) Bron: eigen verwerking OFF # Beschrijving van een vlak 412 0.0 0.0 0.0 0.0 12.0 0.0 6.0 12.0 0.0 6.0 0.0 0.0 4 0 1 2 3 255 0 0

Volgens Mukundan (2012) moet men de waarde voor het aantal randen in een object steeds gelijkstellen aan 0. De OFF-bestanden in de Princeton Shape Benchmark worden op dezelfde manier beschreven maar daar wordt expliciet vermeld dat er geen rekening moet gehouden worden met deze waarde (http://shape.cs.princeton.edu/benchmark/documentation, 12 juli 2013).

2.1.5 XYZ

Het meest eenvoudige formaat dat men in deze studie onderzoekt is het XYZbestandsformaat. Zoals de naam doet vermoeden bevat het formaat enkel punten met een x-,yen z-coördinaat. Het formaat biedt geen mogelijkheid om vlakken te definiëren. De weergave van dergelijk bestand in een viewer levert dus enkel een puntenwolk op. Indien men toch een 3D-object wenst te verkrijgen uit een XYZ-bestand dan kan men, mits gebruik van geschikte software, uit de puntenwolk het object modelleren. In het boek van Lombard (2008) wordt beschreven hoe een gebruiker met het programma SolidWorks een object kan modelleren uit een XYZ-bestand. SolidWorks is maar één van de vele programma’s die dergelijke functies voorziet (Lombard, 2008).

20

De inhoud van een XYZ-bestand is bijzonder eenvoudig: een lijst met punten. Alles wat men na het hekje schrijft kan men als commentaarregel beschouwen. Witregels in het bestand zijn toegelaten. Indien gewenst is het mogelijk om aan de punten een kleur toe te kennen. Dit kan door achter de benoeming van ieder punt een RGB waarde te schrijven. Het bestandsformaat kan men zien als vereenvoudigde versie van het OFF-formaat (2.1.4 ). Het OFF-formaat wordt in diverse boeken en wetenschappelijke artikels beschreven. Een beknopt overzicht kan men vinden in Mukundan (2012).

Tabel 14: XYZ-bestand ter illustratie Bron: eigen verwerking # XYZ-bestand # Sarah 0.0 0.0 0.0 0.0 12.0 0.0 6.0 12.0 0.0 6.0 0.0 0.0 6.0 12.0 6.0

commentaarregel; commentaarregel; start puntenlijst;

einde puntenlijst;

2.1.6 DXF

Het Drawing Interchange Format of Drawing Exchange Format is een CAD-dataformaat. Het open formaat is ontwikkeld door Autodesk met de bedoeling de interoperabiliteit van de data te verzekeren tussen AutoCAD en andere programma’s. De DXF-specificaties op de website van Autodesk19 beschrijven de toepassingsmogelijkheden en het gebruik van DXF. Het formaat heeft zowel een ASCII- als een binaire versie en is opgebouwd uit verschillende delen (header, classes, tables, blocks, entities, objects, thumbnails en een end-of-file marker) die hieronder aan bod komen. De binaire versie kan sneller geladen worden en is compacter maar voor archiveringsdoeleinden heeft de ASCII-versie de voorkeur. Een niet te onderschatten nadeel van ASCII-DXF is de bestandsgrootte (tot 8 keer groter dan het oorspronkelijke DWG bestand). Een ander probleem is het gebrek aan backward compatibility20 mogelijkheden bij de meest recente versies. Ondanks deze nadelen heeft DXF zich ontwikkeld tot een de facto standaard voor de uitwisseling (import en export) van CAD19

http://usa.autodesk.com/adsk/servlet/item?siteID=123112&id=12272454&linkID=10809853, 16 april 2013. Wanneer een product de plaats van een ouder product overneemt maar kan blijven werken met de software of toebehoren van het oudere product dan is het achterwaarts compatibel. 20

21

bestanden. Vaak zal men van een DXF-bestand spreken als het gaat om een ASCII- DXF. Wanneer men toch opteert voor de binaire versie dan zal men dit duidelijk maken door te spreken van een binaire DXF. Bovendien begint de binaire versie altijd met een specifieke 22byte identificatiestring. Een derde, minder gekende vorm van DXF is DXB. Dit is de vereenvoudigde binaire versie. Deze bestanden zijn nog compacter dan de binaire DXF en worden ervan onderscheiden door een 19-byte identificatiestring in plaats van een 22-byte identificatiestring.

Het formaat is een gelabelde datarepresentatie omdat alle elementen voorzien zijn van een geheel getal (0 tot 999). Dit getal vormt de code waarvan de waarde aangeeft welk type dataelement er volgt op de volgende regel. Alle codes zijn te raadplegen in de DXF-specificaties21 en kan men toepassen in alle DXF-bestanden. In tabel 15 vindt u een beknopt overzicht van de codes en hun bijhorende datatype. Zo worden bijvoorbeeld de codes 0 tot 9 gevolgd door Strings en zal elke code gebruikt worden in een specifieke situatie. De code 0 indiceert het begin van een entity of table of is mogelijks de indicator voor het einde van het bestand. Code 2 wordt gebruikt voor namen van sections, blocks, tables, enz…Soms is het mogelijk dat de beschrijving van de codes verschillend is voor bepaalde applicaties maar dit wordt dan vermeld in het bestand. Het DXF-formaat kan zo goed als alle informatie weergeven die een gebruiker specifieert in de tekening.

Tabel 15: Beknopt overzicht van de codes naargelang hun datatype Bron: naar http://images.autodesk.com, 16 april 2013 Code

Datatype

0-9

String

10-59

Reëel getal (bv. coördinaten)

60-73

Integer

210- 239

Reëel getal

999

Commentaar

De beschrijving van objecten en entiteiten is verschillend. Het grote onderscheid hierbij is dat objecten geen geografische representatie hebben terwijl dit voor entiteiten wel voorzien is. Het is gebruikelijk dat men bij de aanmaak van een DXF eerst een commentaarregel invoert 21

http://images.autodesk.com, 16 april 2013.

22

met informatie over het programma, de auteur en de aanmaakdatum. Hierop volgt voor ieder DXF-bestand de code 0. Deze geeft het section-commando aan, gevolgd door de code 2 die aantoont over welke sectie het gaat. De headersectie bevat informatie over de tekening die enkel relevant is wanneer het gaat om DXF-bestanden die speciaal voor AutoCAD toepassingen zijn aangemaakt. In dit geval bevat de header het versienummer, de specificaties, de huidige layer, de rasterafstand, toleranties, opvullingen, patronen,... Indien het bestand enkel gebruikt wordt voor de overdracht van geometrie is deze uitgebreide header overbodig. In dit geval zal de header er ongeveer uitzien zoals in tabel 16. De variabelen en codes worden eveneens gespecifieerd in de DXF-specificaties. In de sectie ‘classes’ wordt informatie opgeslagen over de gedefinieerde klassen waarvan de resultaten tevoorschijn komen in de secties blocks, entities en objects. Een klasse-definitie is onderworpen aan een vaste hiërarchie waarbij alle velden verplicht ingevuld worden. Voor meer informatie kan men de DXF-specificaties raadplegen. Een volgende sectie die voorkomt in het DXF-bestand is tables. Deze sectie bevat verschillende soorten tabellen (tabel 18). De volgorde van de tabellen mag willekeurig maar een ‘LTYPE’-tabel moet steeds voor een ‘LAYER’-tabel komen. De naamgeving van de tabellen gebeurt steeds met een hoofdletter. Daarna volgt de sectie ‘Blocks’ waarin alle blokdefinities staan. Een blokmodel is samengesteld uit verschillende entiteiten die beschreven worden tussen de entiteiten block en endblk. Deze beschrijving gebeurt op identieke wijze als in de sectie entities. Blokdefinities zijn nooit genesteld. Dit houdt in dat de entiteiten block - endblk nooit zullen voorkomen tussen andere block en endblk entiteiten. Bij de aanmaak van een blokmodel worden alle entiteiten naar WCS omgezet en zal de nieuwe oorsprong degene zijn die gedefinieerd werd door het blokmodel. Alle entiteiten zullen dus in WCS gekend zijn, gebaseerd op deze oorsprong. Ook de sectie entities komt aan bod. In dit onderzoek is deze sectie de belangrijkste omdat ze de werkelijke objectgegevens bevat. Deze gegevens zijn nodig om de conversie naar andere bestandsformaten te kunnen uitvoeren. De sectie objects bevat het niet-grafische geheel van de tekening. Vaak omvatten ze de AutoCAD woordenboeken. Tot slot is het ook mogelijk dat het bestand een thumbnailimage-sectie bevat. Deze sectie kan enkel voorkomen wanneer er een image preview is opgeslagen samen met het DXF-bestand (http://images.autodesk.com, 16 juli 2013).

23

Tabel 16: Eenvoudige DXF-filefragment (ASCII) Bron: eigen verwerking 999

code 999 gevolgd door commentaarregel;

DXF created from <program name>

commentaarregel;

0

code 0 gevolgd door een String;

SECTION

string: “SECTION” - dit is het sectiecommando dat aangeeft dat er een sectie wordt geopend;

2


HEADER

string: “HEADER” – dit is de header-sectie; hieronder volgen de headervariabelen;

9

code 9 gevolgd door String;

$ACADVER

headervariabele (beschrijft versienummer);

1

code 1 (string specifiek voor deze variabele);

AC1006

AutoCAD database versie R10;

9


$INSBASE

headervariabele (beschrijft insertiepunt dat gedefinieerd werd via het BASE commando);

10

code 10 (specifiek voor deze variabele);

0.0

insertiepunt: x-coördinaat;

20


0.0

insertiepunt: y-coördinaat ;

30


0.0

insertiepunt: z-coördinaat;

9


$EXTMIN

headervariabele linkeronderhoek);

10


0.0

x-coördinaat;

(beschrijft

positie

24

20


0.0

y-coördinaat;

9


$EXTMAX

headervariabele rechterbovenhoek);

10


1000.0

x-coördinaat;

20


1000.0

y-coördinaat;

0

code 0 wordt gevolgd door een String;

ENDSEC

geeft het einde van de header-sectie aan (hierop volgt een andere sectie);

(beschrijft

positie

… Tabel 17: Beschrijving van een eenvoudige lijn bestaande uit punt 1 (3.0, 5.0) en punt 2 (15.0, 20.0) (DXF-formaat / ASCII- versie) Bron: eigen verwerking 0


SECTION

String: ‘Section’ – sectiecommando dat aangeeft dat er een sectie wordt geopend;

2


HEADER

header-sectie wordt geopend en zal hieronder verschillende header variabelen beschrijven;

9 $ACADVER

headervariabele;

1 AC1012 0 ENDSEC 0

einde van de headersectie;

25

SECTION 2 ENTITIES

openen van een nieuwe sectie;

999

code 999 gevolgd door commentaarregel;

sectie entiteiten wordt geopend en gevolgd door de entiteitvariabelen;

0 LINE

deze commentaarregel wordt beschreven in layer 0;

8 0

code 8 staat voor de layername;

10 3.0

beschrijft de x-coördinaat van de lijn; x-coördinaat;

20 5.0

beschrijft de y-coördinaat van de lijn; y-coördinaat;

11 15

beschrijving van de tweede x-coördinaat (punt twee van de lijn); x-coördinaat;

21 20

beschrijft de tweede y-coördinaat; y-coördinaat;

0 ENDSEC 0 EOF

einde van de entiteitsectie; einde van het bestand;

26

Tabel 18: Lijst met verschillende types tabellen Bron: http://images.autodesk.com, 16 april 2013 Definitie

Beschrijving

APPID

Tabel die verschillende applicaties beschrijft

BLOCK_RECORD

Tabel met block referenties

DIMSTYLE

Tabel met de dimensiestijl

LAYER

Tabel met layers

LTYPE

Tabel met verschillende lijntypes

STYLE

Tabel met tekststijlen

UCS

Coördinatentabel

VIEW

Tabel met views

VPORT

Tabel met verschillende viewports

De nieuwe versies van AutoCAD bevatten steeds meer nieuwe codes. Het is wel opmerkelijk dat men in een DXF-bestand niet werkt met een RGB kleurenpalet maar dat men de kleur per entiteit toekent met behulp van code 62. Deze code wordt gevolgd door de AutoCAD kleurindex (cijfer tussen 1 en 255). AutoCAD voorziet wel een RGB kleur op het scherm maar dus niet in het DXF-bestand (http://images.autodesk.com, 16 april 2013).

2.1.7 VRML

Virtual Reality Modelling Language of kortweg VRML is een markuptaal voor de beschrijving van interactieve 3D-objecten en - werelden. Deze taal wordt vaak gezien als een uitbreiding op HTML (HyperText Markup Language). De taal is ontwikkeld door het Web3D Consortium en wordt nog steeds door deze organisatie onderhouden. Het VRML-formaat is een hiërarchische taal en enkel beschikbaar als ASCII-code. VRML-bestanden worden opgeslagen met extensie .vrml of als .wrl en kunnen met diverse viewers bekeken worden. Andere extensies zijn ook mogelijk, zoals na het comprimeren van dergelijke bestanden met de GZIP-tool (.wz of .wrz). De gecomprimeerde VRML-bestanden zijn tot twee derden kleiner dan een overeenkomstige beschrijving in ASCII-formaat. De taal kan statische en geanimeerde 3D-objecten weergeven die eventueel hyperlinks kunnen bevatten naar andere media (bv. tekst, geluiden, films en afbeeldingen). De huidige versie 2.0 noemt men Moving Worlds en biedt ondersteuning voor eenvoudige walk through scènes, multimediaeffecten en

27

real-time interacties. Het integreren van hyperlinks in de code wordt gebruikt voor het ophalen en combineren van onderdelen van andere websites of om van de ene virtuele wereld naar de andere over te gaan (hyperjump). VRML streeft verschillende doelstellingen na waaronder

combinatiemogelijkheden,

uitbreidingsmogelijkheden

en

platformonafhankelijkheid (Mollet, 2004; Cao et al., 2012).

VRML is naast een opslagformaat ook een universeel uitwisselingsformaat voor geïntegreerde 3D beelden en multimedia. Het formaat kent tal van toepassingsgebieden zoals engineering,

wetenschappelijke

weergaves,

multimediapresentaties,

entertainment,

webpagina’s en virtuele werelden. Mede door zijn populariteit blijft VRML zich verder ontwikkelen. In 1995 ontstond de VRML 1.0 specificatie die in 1997 vervangen werd door de VRML 97 of VRML 2.0 specificatie. De laatste evolutie heeft er voor gezorgd dat men langzaamaan over stapt naar X3D en Java3D. Men kan X3D dus bestempelen als de opvolger maar VRML 2.0 blijft compatibel met X3D (Cao et al., 2012).

Tabel 19: Opbouw van een VRML-bestand Bron: eigen verwerking #VRML V2.0 utf8 # Beschrijving van een cilinder Shape { appearance Appearance { material Material { }

header; commentaar/uitleg; node en node-types;

veld; } geometry Cylinder { height 2.0 radius 1.0 }

velden;

}

28

Het bestand begint steeds met een header (commentaarregel) die aantoont dat het desbetreffende bestand een VRML-bestand is conform aan versie 2.0 en gecodeerd volgens UTF822. Het ‘hekje’ geeft aan dat alles wat erop volgt als commentaar wordt aanzien. Hieronder begint de eigenlijke inhoud die men de scene-graph noemt. Deze scene-graph bestaat uit nodes en node-types. De nodes beschrijven objecten en hun eigenschappen in een hiërarchische volgorde. Binnen de accolades van een node-type kunnen velden voorkomen. Deze velden bezitten parameters die nodig zijn voor de opbouw van de objecten. De volgorde van de velden is willekeurig aangezien de node hierdoor niet wordt beïnvloed. De velden alsook de node-types zijn hoofdlettergevoelig. De velden beginnen steeds met een kleine letter (bv. height) en de node-types beginnen altijd met een hoofdletter (Ames et al., 1997; Baerten et al., 1998; Cao et al., 2012; http://www.web3d.org/x3d/specifications/vrml/, 5 april 2013).

Figuur 2: Scene-graph van het voorbeeld uit tabel 19 Bron: eigen verwerking

Het resultaat van de VRML-code in tabel 19 is een cilinder met een hoogte van 2 meter en een straal van 1 meter. Het is belangrijk te vermelden dat de meeteenheden in een VRMLbestand opgegeven zijn in meter. Daarnaast worden de hoeken in radialen beschreven en de kleuren in RGB waarden variërend tussen 0 en 1. Het voorbeeld in tabel 19 is een eenvoudig model maar het kan de basis vormen voor de opbouw van een virtuele omgeving. Deze omgeving kan ontstaan door het samenvoegen van meerdere objecten via een group node. VRML-modellen maken gebruik van een 3D cartesisch assenstelsel. De objecten worden steeds in het midden van de virtuele wereld gecentreerd indien de locatie niet opgegeven is in 22

Het 8 bit Unicode Transformation Format is een gestandaardiseerde tekencodering met een variabele lengte. Dit wil zeggen dat niet elk teken evenveel bytes gebruikt. De voorstelling kan gebruik maken van 1 tot 4 bytes afhankelijk van het teken. De standaard kan meer dan 24 000 tekens coderen van verschillende talen en is ideaal als uitwisselingsformaat (http://www.vislab.uq.edu.au/users/manuals/vrml97/slides, 3 april 2013)

29

de file. In dit geval overlappen de diverse objecten elkaar (tabel 20–figuur 3) (Ames et al., 1997; http://www.vislab.uq.edu.au/users/manuals/vrml97/slides, 3 april 2013).

Tabel 20: VRML-file met meerdere shape nodes Bron: naar Ames et al.,1997 #VRML V2.0 utf8 # Space Station Shape { appearance Appearance { material Material { } } geometry Box { size 1.0 1.0 1.0 } } Shape { appearance Appearance { material Material { } } geometry Sphere { radius 0.7 } } Shape { appearance Appearance { material Material { } } geometry Cylinder { radius 1.25 height 0.05 } } Shape { appearance Appearance { material Material { } } geometry Cylinder { radius 0.4 height 2.0 } } Shape { appearance Appearance { material Material { } } geometry Cylinder { 30

radius 0.3 height 3.0 } } Shape { appearance Appearance { material Material { } } geometry Cylinder { radius 0.1 height 6.0 } }

Figuur 3: Resultaat na uitvoering van de VRML-code (tabel 20) in de Cortona3D viewer Bron: eigen verwerking

De cilinder uit tabel 19 maakt deel uit van de groep basic shape nodes. Deze shape nodes zijn de bouwstenen van de VRML-wereld en bouwen modellen met een zekere kleur en textuur (appearance nodes) en een welbepaalde vorm of structuur (geometry nodes). Tot deze laatste groep behoren de kubus, de kegel, de cilinder, de bol en tekst. Voor meer realistische werelden moet men gebruik maken van gecompliceerdere nodes. Een voorbeeld hiervan is de IndexedFaceSet node die 3D lichamen kan creëren uit een verzameling van polygonen. Het

31

gebruik van deze IndexedFaceSet is geïllustreerd in tabel 21. Het uitvoeren van de code geeft als resultaat een 3D huis. In tabel 22 wordt een kort overzicht gegeven van de geavanceerde nodes. Voor gedetailleerde uitleg kan men het werk van Çöltekin et al. (1999) raadplegen. Naast de geometry nodes zijn ook de appearance nodes in dit onderzoek van belang. Hier kan men alle kleuren textuur informatie toevoegen. Binnen de appearance node is het mogelijk om een material node te definiëren die zes velden kan beschrijven: diffuseColor (kleur van de geometrie), emmisiveColor (gloed van het object), ambientIntensity (reflectie van licht op het object), shininess (glans), specularColor (spiegelend effect) en transparency (transparantie) (Ames

et

al.,

1997;

Çöltekin

http://www.vislab.uq.edu.au/users/manuals/vrml97/slides,

et 3

al.,

1999;

april

2013;

http://www.web3d.org/x3d/specifications/vrml/, 5 april 2013).

Tabel 21: Gebruik van de IndexedFaceSet node Bron: eigen verwerking #VRML V2.0 utf8 Shape { appearance Appearance { material Material { } } geometry IndexedFaceSet { coord Coordinate { point [0.0 0.0 0.0 0.0 12.0 0.0 6.0 12.0 0.0 6.0 0.0 0.0 6.0 12.0 6.0 6.0 0.0 6.0 0.0 0.0 6.0 0.0 12.0 6.0 3.0 0.0 9.0 3.0 12.0 9.0] } coordIndex [0, 1, 2, 3, -1, 3, 2, 4, 5, -1, 0, 6, 7, 1, -1,0, 3, 5, 8, 6, -1, 2, 1, 7, 9, 4, -1, 5, 4, 9, 8, -1, 6, 8, 9, 7] } }

Tabel 22: Overzicht geavanceerde nodes in VRML Bron: naar http://www.web3d.org/x3d/specifications/vrml/, 5 april 2013 Advanced node

Beschrijving

Voorbeeld

Pointset

Kan enkel een puntenwolk

Shape{ appearance Appearance { material Material {emissiveColor 1 1 1 }} geometry PointSet { coord Coordinate {point [ 1.0 1.0 1.0 -1.0 -1.0 -1.0 1.0 -1.0 1.0 ] }

weergeven. De punten kunnen van elkaar onderscheiden worden door

32

color Color { color [ 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 ] }

toekenning van een kleur maar bevatten geen topologische relaties. IndexedLineSet

IndexedFaceSet

ElevationGrid

Extrusion

}

Shape{ appearance Appearance { topologische relaties. De material Material {emissiveColor 1 1 1 }} geometry IndexedLineSet { coördinaten worden coord Coordinate { gedefinieerd in een lokaal point [ 0 0 0, 1 0 0, 1 1 0, 0 1 0 ] } coordIndex [0 1 2 3 0 ] coördinatensysteem. color Color { color [1 0 0, 0 1 0, 0 0 ]} Kleurtoekenning is mogelijk. colorIndex [0 1 2 0 1 ] colorPerVertex TRUE } } Shape{ Qua opbouw goed te appearance Appearance { material Material { vergelijken met de }} geometry IndexedFaceSet { IndexedLineSet maar hier coord Coordinate { point [-1 -1 -1, 1 -1 -1, 1 worden vlakken gegenereerd. 1 - 1, -1 1 -1, -1 -1 1, 1 -1 1, 1 1 1, -1 1 1 ] Het begin van een nieuw vlak } coordIndex [3 2 1 0 -1, 4 5 6 7 –1, 0 1 5 4 wordt aangegeven met ‘-1’. 1, 5 1 2 6 -1, 7 6 2 3 -1, 0 4 7 3 ] Aan de vlakken kunnen color Color { color [1 0 0, 0 1 0, 0 0 1]} kleuren toegekend worden. colorIndex [0 2 1 0 1 0] colorPerVertex FALSE creaseAngle 0 solid TRUE ccw TRUE convex TRUE } } Shape { Wordt gebruikt om een appearance Appearance {material Material { hoogtemodel te genereren. In }} geometry ElevationGrid{ plaats van een xDimension 4 coördinatenlijst wordt hier zDimension 4 xSpacing 1 gebruikt gemaakt van punten zSpacing 1 die op een regelmatige height [ 0 0 0 0, 0 1 1 0, 0 1 1 0, 0 0 0 0] ccw TRUE afstand van elkaar staan. solid TRUE creaseAngle 0 }} Shape { Wordt gebruikt om een vlak appearance Appearance {material Material { langsheen een bepaald pad }} Creëert 3D polylijnen met

33

geometry Extrusion{ crossSection [ -1 -1, -1 1, 1 1, 1 -1, -1 -1] spine [0 -1 0, 0 1 0] orientation [0 0 1 0, 0 0 1 0] scale [1 1, .5 .5] beginCap FALSE endCap FALSE ccw TRUE convex TRUE solid FALSE creaseAngle 0 }

uit te rekken zodat een 3Dobject verkregen wordt.

} Figuur 3 toont aan dat, indien geen positie bepaald is, alle objecten op dezelfde plaats staan en elkaar overlappen. Om dit op te lossen kan men gebruik maken van de transform node. Deze node beschrijft de translatie die van toepassing is op alle children van die node in de scenegraph. De herpositionering kan gebeuren via een lokaal assenstelsel of een coördinatenstelsel. Ook rotatie en verschaling zijn mogelijk. In tabel 23 wordt het gebruik van deze node geïllustreerd (Ames et al.,1997; http://www.web3d.org/x3d/specifications/vrml/, 5 april 2013).

Tabel 23: VRML transform node Bron: eigen verwerking Transform { translation -2.0 -1.0 0.0 children [ Shape { appearance Appearance { material Material { } } geometry Cylinder { radius 0.3 height 6.0 top FALSE } } ] }

34

Vaak komt het voor dat verschillende objecten dezelfde geometrie en/of appearance hebben. In dit geval zou men dezelfde nodes meerdere malen moeten dupliceren. Om dit te vermijden en efficiënter te werken kan men een naam definiëren voor een bepaalde node. Deze naam moet toegekend worden op de plaats waar de node voor het eerst voorkomt in het bestand. Later kan men die naam weer aanhalen wanneer men diezelfde node wenst te gebruiken. Tabel 24 toont een fragment uit een VRML-code waar gebruik is gemaakt van de DEFsyntax. DEF moet steeds in hoofdletters en kan gebruikt worden voor iedere node. De naam mag zowel cijfers als letters bevatten maar moet uniek zijn binnen het VRML-bestand. In tabel 25 wordt deze node opnieuw gebruikt door het aanroepen van de USE-syntax (Ames et al.,1997; http://www.web3d.org/x3d/specifications/vrml/, 5 april 2013).

Tabel 24: DEF-syntax uit fragment VRML-code Bron: eigen verwerking Shape { appearance Appearance { material DEF RedColor Material { diffuseColor 1.0 0.0 0.0 } } geometry . . . } Tabel 25: USE-syntax uit fragment VRML-code Bron: eigen verwerking Shape { appearance Appearance { material USE RedColor } geometry . . . }

Het gebruik van DEF en USE vermijdt het dupliceren van de code en zorgt ervoor dat de bestandsgrootte afneemt. Bovendien is een snelle aanpassing van de code mogelijk en versnelt dit het verwerkingsproces van de browser (http://www.web3d.org/x3d/specifications/vrml/, 5 april 2013).

35

Een virtuele wereld opbouwen is niet enkel het object bouwen maar er ook voor zorgen dat het er reëel uitziet. Deze details zelf beschrijven in een VRML-bestand neemt veel tijd in beslag en is niet eenvoudig. Texture mapping biedt hier de oplossing. Deze techniek geeft het object een realistische aanblik door de details van een echte foto te gebruiken. Deze foto wordt als het ware op het object gekleefd waardoor de fijnste details worden nagebootst. Het definiëren van de foto gebeurt bij appearance. Om de realiteitszin nog te vergroten kan men drie types VRML-lichten gebruiken (point light, directional light en spot light) waarvan de intensiteit, de warmte en de kleur kunnen ingesteld worden (Figuur 4). Om alles in zijn context te zien is het aangeraden om een passende achtergrond te creëren (Ames et al.,1997).

Figuur 4: Gebruik van texture mapping en belichting Bron: http://www.vislab.uq.edu.au/users/manuals/vrml97/examples, 3 april 2013

Vele acties zijn te complex voor VRML nodes, daarom is het mogelijk om program scripts te schrijven en deze in de VRML-code onder te brengen (script node). De scripts kunnen geschreven worden in Java, JavaScript, VRMLscript of in andere talen. In Cao et al. (2012) maakt men een virtueel VRML-model met behulp van Java-code. Ze hebben hun systeem met succes getest met de Cortona VRML Client 4.2 op diverse platformen.

Het gebruik van VRML biedt enkele voordelen maar heeft ook enkele tekortkomingen. Een eerste pluspunt is dat de taal platformonafhankelijk is en dus toepasbaar op elk systeem. Bovendien is werken met VRML ook mogelijk via verbindingen op lage bandbreedte waardoor de taal niet alleen toegankelijk is voor een selectieve doelgroep maar voor een breed 36

publiek. Het model kan te allen tijde uitgebreid worden, ook met andere codes (Cao et al., 2012). Een minpunt is dat de VRML-wereld volledig vast ligt wanneer de file ingeladen wordt. Bovendien is de codering vrij lang voor een eenvoudige animatie en tot slot is het gebrek aan ondersteuning voor 2D een groot nadeel (Mollet, 2004).

2.1.8 X3D

De opvolger van VRML 2.0 is X3D en kan men dus bestempelen als de derde generatie VRML. X3D werd aanvaard als een ISO23/IEC24 19775 standaard in 2004. Tot op heden wordt de standaard nog steeds bijgewerkt en worden de mogelijkheden verruimd. Het Web3D Consortium steunt actief verschillende werkgroepen en een geïnteresseerde community van gebruikers die meehelpen aan de uitbreiding en verbetering van de standaard. Het is een kosteloos open source en ISO-bekrachtigd standaardformaat voor de beschrijving en uitwisseling van 3D-objecten/werelden. X3D verbetert VRML met nieuwe functies, geavanceerde API’s25 en biedt een striktere conformiteit. Het is een component-gebaseerde architectuur die gebruik maakt van profielen om een modulaire aanpak te verzekeren. Hierdoor

is

backward

compatibility

mogelijk

(Furht,

2008;

http://www.web3d.org/x3d/specifications/x3d/, 6 april 2013).

De specificaties van de X3D-standaard zijn vrij te raadplegen op de website van het Web3Dconsortium26. De X3D scene-graph is gebaseerd op XML (.x3d) of op VRML (.x3dv). Deze twee tekstuele bestandsformaten worden in tabel 26 en tabel 27 beschreven. Naast deze tekstuele codering bestaat er ook een binaire codering (.x3db). De binaire codering levert kleinere X3D-bestanden op die sneller geladen worden in een viewer (Brutzman & Daly, 2007).

23

International Organization for Standardization. International Electrotechnical Commission. 25 Een Application Programming Interface zorgt ervoor dat verschillende computerprogramma’s of onderdelen van die programma’s met elkaar kunnen communiceren. De API zorgt vaak voor de scheiding tussen verschillende abstractielagen. Hierdoor kan een applicatie op een hoog abstractieniveau werken en minder abstract werk laten verrichten door andere programma’s. 26 Zie http://www.web3d.org. 24

37

Tabel 26: Beschrijving van twee vlakken in X3D-code (type .x3d) Bron: eigen verwerking 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

<X3D profile="Interchange" version="3.2" xmlns:xsd="http://www.w3.org/2001/XMLSchema-instance" xsd:noNamespaceSchemaLocation="http://www.web3d.org/specifications/x3d3.2.xsd"> <Scene> <Shape> <Shape>

Tabel 27: Beschrijving van twee vlakken in X3D-code (type .x3dv) Bron: eigen verwerking Shape { geometry IndexedFaceSet { coordIndex [ 0, 1, 2, 3] coord Coordinate { point [ 0.0 0.0 0.0, 0.0 12.0 0.0, 6.0 12.0 0.0, 6.0 0.0 0.0] } } } Shape { geometry IndexedFaceSet { coordIndex [ 0, 1, 2, 3] coord Coordinate { point [ 6.0 0.0 0.0, 6.0 12.0 0.0, 6.0 12.0 6.0, 6.0 0.0 6.0] } } }

38

De code in tabel 26 beschrijft twee vlakken met elk vier hoekpunten in X3D codering gebaseerd op XML (.x3d). Het bestand bestaat uit verschillende delen. In regel 1 tot 9 wordt er gedetailleerde informatie meegegeven over de syntaxregels van het bestand (XMLschema’s). Een groot voordeel van X3D is de XML-validatie. XML controleert of de documenten well-formed zijn waardoor de kwaliteit van een X3D-scene verzekerd wordt. Regel 1 beschrijft welke codering toegepast is om de tekens (characters) in het document weer te geven. Meestal maakt men gebruikt van de UTF-8 codering. De daarop volgende regels (regels 3-9) beschrijven de X3D-versie en XML-schema’s die nodig zijn. Het feit dat X3D-bestanden backwards compatible zijn is een groot pluspunt. Na deze regels volgt de beschrijving van het object/de objecten die vervat zijn in de scene-graph. Net zoals bij VRML (2.1.7) gebruikt men shape nodes. Tabel 27 geeft hetzelfde resultaat als tabel 26 maar het X3D-bestand is nu gebaseerd op VRML-syntax. Merk op dat hier geen extra informatie opgenomen is zoals bij tabel 26 (regels 1-9) het geval is. Bovendien is het niet noodzakelijk dat er een scene-graph gedefinieerd wordt. Een directe opsomming van de shape nodes is mogelijk. Dit biedt een overzichtelijk en leesbaar bestand. De opbouw van een X3D-bestand is gelijkend op VRML aangezien X3D de opvolger is. Om de X3D inhoud beter te begrijpen wordt dus verwezen naar de uitleg bij VRML (2.1.7) (Brutzman & Daly, 2007).

Voordelen X3D (http://www.web3d.org, 6 april 2013): 

open source, dus geen licenties nodig;



compatibel met de volgende generatie van grafische files (bv. SVG27);



eenvoudige updating;



ruime toepassingsmogelijkheden;



de weergaves zijn van hoge kwaliteit, real-time, interactief en kunnen zowel audio als video bevatten;



eenvoudige en specifieke code die gemakkelijk op te bouwen is.

2.1.9 GML en CityGML

2.1.9.1

GML

Geography Markup Language (GML) is een XML gebaseerde taal voor de opslag, uitwisseling en weergave van geografische data. De taal is ontwikkeld door het OGC en wordt 27

Scalable Vector Graphics.

39

eveneens door de organisatie verder beheerd. In een GML-document kunnen gegevens verzameld worden die objecten beschrijven. Het is mogelijk om de vorm van objecten te beschrijven (geometrisch aspect) maar ook topologische en temporele karakteristieken kunnen opgenomen worden (Burggraf, 2006; http://www.opengeospatial.org/standards/gml, 7 april 2013). Het GML-bestand bestaat uit een aantal XML-schema’s die de basis vormen voor het coderen van verschillende geografische gegevens. Het geheel van deze schema’s vormt het core GML-model. Aangezien het niet mogelijk is om alle mogelijke features te definiëren in het core schema kunnen hiervoor GML applicatieschema’s worden gebruikt. Deze schema’s worden door gebruikers opgemaakt en kan men aanspreken voor bepaalde toepassingen (Burggraf, 2006). Indien een GML-toepassing gebruik maakt van schema’s die bij aanvang niet in het core model aanwezig zijn moeten deze schema’s aangeroepen worden zoals in tabel 28.

Tabel 28: Aanroep van het geometry XML-schema Bron: eigen verwerking xmlns:gml= ‘http://www.opengis.net/gml’

In tabel 28 is de aanroep van het geometry schema weergegeven. Een schema wordt steeds aangeroepen door “xmlns”. Daarop volgt de namespace dewelke hier “gml” noemt. Een namespace is de unieke naam die aangeeft uit welk schema het gebruikte element afkomstig is. Bij de naam van het element wordt dan een prefix toegevoegd, gevolgd door een dubbelepunt en de naam (<prefix:naamElement>). Zo zal men bijvoorbeeld bij het element “”

uit het geometry schema de volgende aanduiding moeten voorzien:

“”. Stel dat men hieraan verzaakt dan zal het GML-document niet weten uit welk schema

het

element

afkomstig

is

en

bijgevolg

een

foutmelding

geven

(http://www.opengeospatial.org/standards/gml, 10 april 2013). De vooraf gedefinieerde XML-schema’s bevatten dus een aantal basiselementen. In dit onderzoek wordt er vooral gefocust op de geometrische eigenschappen. Daarom zijn de basiselementen van het geometrisch type vermeld in tabel 29. Binnen alle basiselementen 40

wordt er gebruik gemaakt van het element coord of coordinates om objecten te beschrijven (http://www.opengeospatial.org/standards/gml, 10 april 2013).

Tabel 29: Basiselementen (type: geometry) Bron: naar http://www.opengeospatial.org/standards/gml, 10 juli 2013 XML-schema property type

Geometry object types

PointPropertyType

Point

CurvePropertyType

AbstractCurve LineString Curve OrientableCurve CompositeCurve

SurfacePropertyType

AbstractSurface Polygon Surface OrientableSurface CompositeSurface

SolidPropertyType

AbstractSolid Solid CompositeSolid

MultiPointPropertyType

MultiPoint

MultiCurvePropertyType

MultiCurve

MultiSurfacePropertyType

MultiSurface

MultiSolidPropertyType

MultiSolid

MultiGeometryPropertyType

MultiGeometry

PointArrayPropertyType

Point(s)

CurveArrayPropertyType

AbstractCurve(s) LineString(s) Curve(s) OrientableCurve(s) CompositeCurve(s)

SurfaceArrayPropertyType

AbstractSurface(s) Polygon(s)

41

Surface(s) OrientableSurface(s) CompositeSurface(s) SolidArrayPropertyType

AbstractSolid(s) Solid(s) CompositeSolid(s)

Tabel 30: Eenvoudig GML-bestand Bron: eigen verwerking

feature (rootelement);

<span>150

element gedefinieerd in applicatieschema;

200

element gedefinieerd in applicatieschema;

geometrisch object, gedefinieerd in het GML schema. CenterLineOf beschrijft de middellijn van de brug. Binnen dit element volgt een ander element namelijk LineString. Dit element bevat een reeks punten die dan verbonden worden door rechte lijnen;

geometrisch object LineString gevolgd door de individuele punten door middel van het element pos;

150 200 200 200

geometrische object LineString wordt gesloten; geometrisch object centerLineOf wordt gesloten; hoofdelement wordt gesloten, dit is tevens het einde van het GML-bestand;

GML wordt opgebouwd uit objecten die men ook wel features noemt. De beschrijving van een feature gebeurt door een aantal properties. Deze eigenschappen vertellen vaak iets meer over de naam en het type object (http://www.opengeospatial.org/standards/gml, 10 juli 2013) Men kan dus stellen dat het GML-bestand één of meerdere features bevat en mogelijks ook

42

geometrische objecten. Deze geometrische eigenschappen zijn geen vereiste voor het bestaan van een GML-bestand. Een geometrisch object definieert de locatie aan de hand van coördinaten. In bovenstaand voorbeeld (tabel 30) is een feature en tevens het rootelement. Alle elementen tussen en beschrijven deze feature. De elementen <span> en zijn specifieke kenmerken van en worden gedefinieerd in het applicatieschema (http://www.opengeospatial.org/standards/gml, 7 juli 2013).

Een GML-bestand kan opgeslagen worden als een .gml - of .xml file en kan gemakkelijk over het internet verspreid worden (http://www.opengeospatial.org/standards/gml, 7 juli 2013).

2.1.9.2

CityGML

CityGML of City Geography Markup Language is een open datamodel. Het is geschikt voor de opslag en uitwisseling van virtuele 3D-stadsmodellen en 3D-landschapsmodellen en wordt als applicatieschema in GML3 (versie 3.1.1) geïmplementeerd. De ontwikkeling startte in 2002 als reactie op de vraag naar de mogelijkheid om een 3D stadsmodel te creëren, dat zowel geometrische, semantische als topologische aspecten kon beschrijven. Doorheen de jaren ontwikkelden zich tal van andere 3D-formaten, maar meestal ontbrak het semantische en topologische gedeelte. CityGML is een bestandsformaat dat zich specifiek toelegt op de creatie van 3D-stadsmodellen en uitbreidingsmogelijkheden voorziet voor specifieke toepassingen. Deze uitbreidingen noemt men ADE’s (Application Domain Extension). Dankzij ADE’s kan men nieuwe eigenschappen aan bestaande CityGML-klassen toevoegen of nieuwe objecten definiëren. Stadsmodellen worden steeds meer en meer gebruikt voor allerlei doeleinden. Niet enkel de gebruikelijke stedelijke objecten (bv. huizen) worden opgenomen maar ook hoogtewaarden, waterelementen, vegetatie,… Het formaat is gebaseerd op de verschillende standaarden waaronder de ISO 191xx reeks, het OGC28 en het W3C Consortium. De 3D-objecten kunnen in verschillende graden van detail worden weergegeven, de zogenaamde detaillevels (http://www.opengeospatial.org/standards/citygml, 7 juli 2013). Dit laat toe dat de analyse en visualisatie van elk 3D-object kan gebeuren in diverse graden van detail. Bovendien is het mogelijk dat van hetzelfde object een combinatie wordt gemaakt van de verschillende detaillevels (LOD’s) waarin het voorkomt. Hieronder volgt een

28

Open Geospatial Consortium.

43

opsomming van de verschillende LOD’s (Kolbe et al., 2005; Li et al., 2008; Mao et al., 2009): 

LoD0: een 2.5D terreinmodel waarover een kaart of luchtfoto kan worden gedrapeerd (het minst gedetailleerde level);



LoD1: blokkenmodel zonder enige dakconstructies of texturen;



LoD2: blokkenmodel met dakconstructies, texturen en vegetatie;



LoD3: architecturale modellen met gedetailleerde dakconstructies, balkons, ramen en andere elementen;



LoD4: is de aanvulling van LOD 3 met interieurstructuren zoals kamers, binnendeuren, trappen en meubels.

De LOD’s zijn ook gekenmerkt door verschillende nauwkeurigheden. De nauwkeurigheden die in de OGC CityGML-standaardspecificaties zijn vooropgesteld zijn afkomstig uit het werk van Albert et al. (2003). Volgens het OGC zijn ze voor discussie vatbaar. De nauwkeurigheden worden uitgedrukt als de standaarddeviatie van de absolute 3D-punten. In tabel 31 zijn deze nauwkeurigheden weer te vinden evenals de geschikte toepassingsgebieden voor iedere LOD. Tabel 31: LOD’s met hun toepassingsgebied en absolute nauwkeurigheid Bron: http://www.ikg.uni-bonn.de, 7 juli 2013 LOD

Toepassingsgebied

Absolute nauwkeurigheid (positie / hoogte)

LOD0

Regionaal niveau & landschappen

LOD1

Regionaal niveau & steden

5m / 5m

LOD2

Steden, stadsgedeeltes & projecten

2m / 2m

LOD3

Stadsgedeeltes, architecturale modellen (exterieur) 0.5m / 0.5m & landmarks

LOD4

Architecturale modellen (interieur) & landmarks

0.2m / 0.2m

Vaak zijn de CityGML-bestanden erg groot (meerdere gigabyte voor grote steden) en is het model heel complex wat de visualisatie ervan bemoeilijkt (Mao et al., 2009). Het model kan wel uitgewisseld worden tussen verschillende GI-systemen zonder verlies aan enige informatie. CityGML wordt door vele commerciële en academische tools ondersteund

44

(http://www.opengeospatial.org/standards/citygml. 7 juli 2013). In dit onderzoek wordt gebruik gemaakt van een vrij beschikbare open source Java class bibliotheek ( zie bijlage 7.1) om een CityGML-bestand te genereren. Met behulp van NetBeans IDE wordt deze code uitgevoerd. Het resultaat hiervan is een CityGML-bestand (tabel 32). Het 3D-object dat hierin gedefinieerd wordt is een 3D-huis in LOD2. Het huis wordt in deze studie gebruikt als onderzoeksobject en wordt concreter toegelicht in 3.2.3 (hoofdstuk 3).

Tabel 32: CityGML-bestand (gegenereerd met de Java class bibliotheek citygml4j) Bron: eigen verwerking 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

0.0 0.0 0.0 6.0 12.0 9.0 0.0 0.0 0.0 0.0 12.0 0.0 6.0 12.0 0.0 6.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 46

87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 6.0 0.0 0.0 6.0 12.0 0.0 6.0 12.0 6.0 6.0 103 0.0 6.0 6.0 0.0 0.0 6.0 0.0 0.0 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 0.0 0.0 0.0 0.0 0.0 6.0 0.0 12.0 6.0 0.0 121 12.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 47

137 138 0.0 0.0 0.0 6.0 0.0 0.0 6.0 0.0 6.0 3.0 0.0 139 9.0 0.0 0.0 6.0 0.0 0.0 0.0 0.0 0.0 0.0 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 6.0 12.0 0.0 0.0 12.0 0.0 0.0 12.0 6.0 3.0 157 12.0 9.0 6.0 12.0 6.0 6.0 12.0 0.0 6.0 12.0 0.0 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 6.0 0.0 6.0 6.0 12.0 6.0 3.0 12.0 9.0 3.0 175 0.0 9.0 6.0 0.0 6.0 6.0 0.0 6.0 176 177 178 179 180 181 182 183 184 185 186 48

187 188 189 190 191 192 0.0 0.0 6.0 3.0 0.0 9.0 3.0 12.0 9.0 0.0 193 12.0 6.0 0.0 0.0 6.0 0.0 0.0 6.0 194 195 196 197 198 190 191 192 193 194 195

Het bestand bevat veel informatie waaronder de geometrische gegevens van het object. De vlakken van het huis zijn gedefinieerd in de regels 84-85, 102-103, 120-121, 138-139, 156157, 174-175, 192-193.

Een CityGML-bestand bestaat uit verschillende modules waarbij een onderscheid gemaakt wordt tussen de core module en de thematische uitbreidingsmodules. De specificatie van elke module gebeurt in een XML-schema dat gedefinieerd is door een unieke XML-namespace. De core module vormt de basis en elke uitbreidingsmodule is hierop gebaseerd. In tabel 33 wordt een opsomming gegeven van de bestaande modules in CityGML 2.0 en tabel 34 geeft een overzicht van de XML-schemadefinities. De core module zal altijd aanwezig zijn in een CityGML-bestand omdat het de basisconcepten en - componenten bevat voor de creatie van een datamodel. Omwille hiervan zal het XML-schema van de core module steeds geïmporteerd zijn in het XML-schema van elke gebruikte uitbreidingsmodules. De uitbreidingsmodules bevatten elk een specifiek thema voor de creatie van een 3D stads- of landschapsmodel. De combinatie van de core module met andere modules vormen CityGML profielen. Wanneer alle modules geïmplementeerd zijn in de core module spreekt men van het CityGML-basisprofiel en wordt dit genoteerd als CityGML[full]. Indien slechts enkele modules zijn opgenomen dan vermeldt men deze in de notatie. Stel dat de modules LandUse, Tunnel en Waterbody worden opgenomen dan is de notatie als volgt ‘CityGML[LandUse, Tunnel, WaterBody]’. De core module zelf importeert de XML-schemabestanden van GML 49

versie

3.1.1

en

OASIS29

extensible

Adress

Language

xAL

(http://www.opengeospatial.org/standards/citygml, 7 juli 2013).

Tabel 33: CityGML modules met bijhorende XML-namespace identificatie en namespace prefix Bron: http://www.opengeospatial.org/standards/citygml, 7 juli 2013 CityGML module

Namespace identificatie

Namespace prefix

CityGML Core

http://www.opengis.net/citygml/2.0

core

Appearance

http://www.opengis.net/citygml/appearance/2.0

app

Bridge

http://www.opengis.net/citygml/bridge/2.0

brid

Building

http://www.opengis.net/citygml/building/2.0

bldg

CityFurniture

http://www.opengis.net/citygml/cityfurniture/2.0

frn

CityObjectGroup

http://www.opengis.net/citygml/cityobjectgroup/2.0

grp

Generics

http://www.opengis.net/citygml/generics/2.0

gen

LandUse

http://www.opengis.net/citygml/landuse/2.0

luse

Relief

http://www.opengis.net/citygml/relief/2.0

dem

Transportation

http://www.opengis.net/citygml/transportation/2.0

tran

Tunnel

http://www.opengis.net/citygml/tunnel/2.0

tun

Vegetation

http://www.opengis.net/citygml/vegetation/2.0

veg

WaterBody

http://www.opengis.net/citygml/waterbody/2.0

wtr

TexturedSurface

http://www.opengis.net/citygml/texturedsurface/2.0

tex

29

Organization for the Advancement of (http://www.opengeospatial.org/standards/citygml, 7 april 2013).

Structured

Information

Standards

50

Tabel 34: Opsomming XML-schema’s met bijhorende namespace identificatie en namespace prefix Bron: http://www.opengeospatial.org/standards/citygml, 7 juli 2013 XML-schema Definitie

Namespace identificatie

Namespace prefix

Geography Markup

http://www.opengis.net/gml

gml

Language 3.1.1 (OGC) Extensible Address

urn:oasis:names:tc:ciq:xsdschema:xAL:2.0 xAL

Language 2.0 (OASIS) Schematron Assertion

http://www.ascc.net/xml/schematron

sch

Language 1.5

De toewijzing van materialen bij CityGML is overgenomen uit X3D (2.1.8) / COLLADA en wordt gedefinieerd als ‘X3DMaterial’. Eveneens kan men gebruik maken van de eigenschappen ‘diffuseColor’, ‘specularColor’ en ‘emissiveColor’. De kleuren worden toegekend door middel van RGB kleurcodering met een waarde voor rood, groen en blauw variërend tussen 0 en 1. Men kan ook een transparantiegraad (transparency) en glans (shininess) toekennen met een waarde tussen 0 (volledig dekkend/zachte glans) en 1 (volledig transparant/scherpe glans). Indien men niet wenst te werken met kleuren kan men ook texturen toekennen via het attribuut ‘textureType’. Hierdoor zal het object veel reëler overkomen bij de waarnemer. De toekenning van de gewenste structuur gebeurt door middel van een Uniform Recource Identifier (URI). De texturen worden op het object aangebracht na aanduiding van de locatie. Een andere mogelijkheid is het gebruiken van een “GeoreferencedTexture”. Dit is een gegeorefereerd bestand (bv. gegeorefereerde orthofoto) dat over het stadsmodel gedrapeerd wordt. Dit kan echter enkel toegepast worden voor horizontale oppervlakken. Als men texturen wenst toe te kennen aan verticale oppervlakken (bv. wanden van een gebouw) dan kan men deze manueel aanbrengen, al dan niet via een URI (http://www.opengeospatial.org/standards/citygml, 7 juli 2013).

CityGML 2.0 is de meest recente versie en bevat enkele uitbreidingen op CityGML 1.0. Het verzekeren van backward compatibility was hierbij de voorwaarde. De 2.0 versie biedt enkele verbeteringen (http://www.opengeospatial.org/standards/citygml. 7 juli 2013): 

het invoeren van thematische modules voor de weergave van tunnels en bruggen;



toevoegingen aan bestaande thematische modules;

51



toevoegingen aan het specificatiedocument;



toevoegingen aan de CityGML codelijsten.

2.2 Opbouw van de Java applicatie met behulp van NetBeans IDE

Bij de aanvang van het onderzoek is eerst de nodige research gedaan naar de opbouw en inhoud van de bestandsformaten. Pas na het verkrijgen van dit inzicht is het mogelijk een degelijke converter te creëren. Er is geopteerd om te programmeren in Java aangezien de nodige basiskennis hiervan in de voorbije jaren van de opleiding werd opgedaan. De code is geprogrammeerd in het softwareprogramma NetBeans IDE. Dit programma is gratis van het internet te downloaden30 en heeft een gebruiksvriendelijke interface. Ter ondersteuning bij het programmeren is gebruik gemaakt van volgende literatuur: Ammeraal (2000), Laan (2007), Barnes & Kölling (2009), Deitel & Deitel (2010). Daarnaast biedt het internet een enorme rijkdom aan informatie wat betreft Java.

De Java-applicatie biedt de mogelijkheid om een sourcebestand in te lezen en te bepalen om welk formaat het gaat. Daarna zal het de juiste klasse aanroepen om de noodzakelijke gegevens te extraheren. Deze data worden dan tijdelijk opgeslagen in een algemeen datamodel. Vervolgens gaat de applicatie na welk targetbestand de gebruiker heeft opgegeven en bepaalt eveneens het bestandsformaat. Daarna zal de applicatie met behulp van de nodige klassen de data wegschrijven naar het opgegeven targetbestand. In figuur 5 is een overzicht gegeven van mogelijke conversies in dit onderzoek. De Java-applicatie en de resultaten van de conversies worden verder besproken in hoofdstuk 3.

30

NetBeans IDE kan gedownload worden via https://netbeans.org/.

52

GML (+CityGML) XYZ

OFF

OBJ

PLY Datamodel

X3D VRML

•X3D •X3DV

STL

DXF

Figuur 5: Overzicht mogelijke conversies in dit onderzoek Bron: eigen verwerking

Het algemeen datamodel kan men zien als tussenstap om over te gaan van het ene formaat naar het andere. Bij de opbouw is geen rekening gehouden met afzonderlijke lijnen maar telkens gekozen om polygonen met minimum drie punten te genereren. Deze keuze is bewust gemaakt omdat in dit onderzoek gekozen is om met 3D-objecten te werken. De implementatie van lijnen in het datamodel is mogelijk mits enkele aanpassingen in de code. Hier is het wel belangrijk te vermelden dat het gebruik van lijnen niet in alle bestandsformaten ondersteund wordt. Dit wordt verder besproken in hoofdstuk 3. Het datamodel in dit onderzoek is dus opgebouwd uit ‘vormen’. Een vorm is samengesteld uit 1 of meerdere vlakken. De vlakken worden bepaald door punten en elk punt heeft een x-, y- en z-coördinaat. In figuur 6 is een schematisch overzicht gegeven van hoe het datamodel is opgebouwd. In het voorbeeld is er sprake van een vorm A die bestaat uit drie vlakken (vlak 1, vlak 2 en vlak 3). Elke vlak bestaat uit minimum drie punten. In het voorbeeld bestaat vlak 1 uit punt a,b,c en d. Vlak 2 is samengesteld uit punt e, f en g. Het laatste vlak is een vijfvlak en bestaat uit punt h, i j, k en l. In tabel 36 is te zien hoe de gegevens van een kubus (tabel 35) worden uitgeschreven volgens het datamodel. 53

Punt a Punt b Vlak 1 Punt c Punt d Punt e Vorm A

Vlak 2

Punt f Punt g Punt h Punt i

Vlak 3

Punt j Punt k Punt l

Figuur 6: Opbouw van het algemeen datamodel in schemavorm Bron: eigen verwerking

54

Tabel 35: Data die in tabel 36 in het algemeen datamodel uitgeschreven zijn Bron: eigen verwerking Vorm

Vlak

Punten

vorm A

Vlak 1

Punt a (-1.0,-1.0,-1.0) Punt b (1.0,-1.0,-1.0) Punt c (1.0,1.0,-1.0) Punt d (-1.0,1.0,-1.0)

Vlak 2

Punt e (1.0,-1.0,1.0) Punt f (-1.0,-1.0,1.0) Punt g (-1.0,1.0,1.0) Punt h (1.0,1.0,1.0)

Vlak 3

Punt i (1.0,1.0,1.0) Punt j (1.0,1.0,-1.0) Punt k (1.0,-1.0,-1.0) Punt l (1.0,-1.0,1.0)

Vlak 4

Punt m (-1.0, 1.0, -1.0) Punt n (-1.0, 1.0, 1.0) Punt o (-1.0,-1.0,1.0) Punt p (-1.0,-1.0,-1.0)

Vlak 5

Punt q (-1.0,1.0, 1.0) Punt r (-1.0, 1.0, -1.0) Punt s (1.0, 1.0, -1.0) Punt t (1.0,1.0,1.0)

Vlak 6

Punt u (1.0,-1.0,1.0) Punt v (1.0,-1.0,-1.0) Punt w (-1.0,-1.0,-1.0) Punt x (-1.0,-1.0,1.0)

55

Tabel 36: Uitgeschreven vorm van het algemeen datamodel Bron: eigen verwerking vo[vl{p(-1.0;-1.0;-1.0),p(1.0;-1.0;-1.0),p(1.0;1.0;-1.0),p(-1.0;1.0;-1.0)}/ vl{p(1.0;-1.0;1.0),p(-1.0;-1.0;1.0),p(-1.0;1.0;1.0),p(1.0;1.0;1.0)}/ vl{p(1.0;1.0;1.0),p(1.0;1.0;-1.0),p(1.0;-1.0;-1.0),p(1.0;-1.0;1.0)}/ vl{p(-1.0;1.0;-1.0),p(-1.0;1.0;1.0),p(-1.0;-1.0;1.0),p(-1.0;-1.0;-1.0)}/ vl{p(-1.0;1.0;1.0),p(-1.0;1.0;-1.0),p(1.0;1.0;-1.0),p(1.0;1.0;1.0)}/ vl{p(1.0;-1.0;1.0),p(1.0;-1.0;-1.0),p(-1.0;-1.0;-1.0),p(-1.0;-1.0;1.0)}]

2.3 Testcases

Na het opbouwen van de applicatie dient deze ook getest te worden. Hieronder volgen 9 verschillende testcases met diverse inputbestanden. De resultaten van deze conversies worden besproken in hoofdstuk 3. Hier worden enkel de testbestanden besproken en nader toegelicht.

Tabel 37: Overzicht testbestanden Bron: eigen verwerking Case

1

Bestandsformaat

Naam

testbestand

testbestand

DXF

case1a.dxf

(DXF 2013)

Object in testbestand

Bron testbestand

vlak met 4 hoekpunten

eigen verwerking

+ vlak met 5 hoekpunten

DXF31

case1b.dxf

(DXF R12/LT2)

vlak met 4 hoekpunten

eigen verwerking

+ vlak met 5 hoekpunten

2

OFF

case2.off

kubus

eigen verwerking

3

CityGML

case3.gml

huis

eigen verwerking

4

OBJ

case4.obj

theepot

Computer Graphics Group32

5 31 32

STL

case5.stl

ster

VDX33

Verder in de tekst zal er gesproken worden over DXF2 wanneer deze versie bedoeld wordt. http://groups.csail.mit.edu/graphics/classes/6.837/F03/models/, 02/08/2013.

56

X3D

case6a.x3d

vrouw

Web 3D Consortium34

X3DV

case6b.x3dv

vrouw

Web 3D Consortium35

7

PLY

case7.ply

straatverlichting

Turk, G.36

8

VRML

case8.vrml

schip

N.N.37

9

XYZ

case9.xyz

puntenwolk (kubus)

Burkardt, J.38

6

In onderstaande figuren wordt een overzicht gegeven van de objecten uit de testbestanden.

Figuur 7: Visualisatie van de objecten uit case 1a en case 1b (DXF) met Autodesk Civil 3D Bron: eigen verwerking

33

http://forums.reprap.org/read.php?88,6830,220658, 2 augustus 2013. http://www.web3d.org/x3d/content/examples/StudentProjects/_pages/page23.html, 2 augustus 2013. 35 http://www.web3d.org/x3d/content/examples/StudentProjects/_pages/page23.html, 2 augustus 2013. 36 http://people.sc.fsu.edu/~jburkardt/data/ply, 2 augustus 2013. 37 http://www.buddycom.com/vrml/tgsmods/index.html, 2 augustus 2013. 38 http://people.sc.fsu.edu/~jburkardt/data/xyz/xyz.html, 2 augustus 2013. 34

57

Figuur 8: Visualisatie van de kubus uit case 2 (OFF) met MeshLab Bron: eigen verwerking

Figuur 9: Visualisatie van het huis uit case 3 (CityGML) met FZK Viewer Bron: eigen verwerking

58

Figuur 10: Visualisatie van de theepot uit case 4 (OBJ) met Autodesk 3ds Max Bron: eigen verwerking

Figuur 11: Visualisatie van de ster uit case 5 (STL) met MeshLab Bron: eigen verwerking

59

Figuur 12: Visualisatie van de vrouw uit case 6a (X3D) en case 6b (X3DV) met Cortona 3D Viewer Bron: eigen verwerking

Bij het formaat X3D en X3DV is gekozen om hetzelfde object te beschrijven. Bij de resultaten in hoofdstuk 3 kan men beiden dan vergelijken.

Figuur 13: Visualisatie van straatverlichting uit case 7 (PLY) met CloudCompare Bron: eigen verwerking

60

Figuur 14: Visualisatie van het schip uit case 8 (VRML) met Cortona 3D Viewer Bron: eigen verwerking

Figuur 15: Visualisatie van de puntenwolk (kubus) uit case 9 (XYZ) met CCViewer Bron: eigen verwerking

61

2.4 Overzicht van de software voor visualisatie van de resultaten

Tabel 38: Overzicht software Bron: eigen verwerking Software

Beschrijving visualiseren

bewerken39

type40

programma opent/importeert volgende bestanden41

Autodesk 3ds Max

C-SL-FT

DXF - OBJ - STL (importeren)

Autodesk Civil 3D

C-SL-FT

DXF

FW

DXF

Autodesk Design Review Autodesk Maya

C-SL-FT

DXF / DXF-OBJ- STL (importeren)

BS Contact

FT

VRML (WRL) - X3D - X3DV

CCViewer

FW

OBJ - PLY - XYZ

CloudCompare

FW

OBJ - PLY - XYZ

Cortona 3D Viewer

FT

VRML

DWG TrueView

FW

DXF

FZK Viewer

FW

GML

Flux Studio

FW

X3D - X3DV - VRML

Free DWG Viewer

FW

DXF

Free WRL Launcher

FW

VRML (WRL) - X3D - X3DV

Geomatic Spark

C

DXF - STL - OBJ - PLY

GML Viewer

FW

GML

Leica Cyclone

C

XYZ

MeshLab

FW

OBJ - PLY - XYZ - OFF - STL - X3D X3DV - WRL

SketchUp

FW

DXF (importeren)

SolidWorks E-Drawings

FW

DXF - STL

Trimble Realworks Viewer

FW

DXF

39

Het bewerken houdt in dat de gebruiker het object kan aanpassen en veranderen. De mogelijkheid om enkel kleur aan te passen wordt hier niet als bewerken gezien. 40 In dit onderzoek worden verschillende types software gebruikt, al dan niet gecombineerd: commercieel (C), freeware (FW), free trial (FT), studenten licentie (SL). 41 Opmerking: dit zijn enkel de formaten die kunnen geopend worden en van belang zijn in dit onderzoek. Dit wil zeggen dat enkel de onderzochte formaten vermeld worden.

62

3. RESULTATEN

3.1 Java-applicatie

De zelf ontwikkelde Java-applicatie vormt de basis van dit onderzoek. In figuur 16 is een UML diagram opgesteld. Dit klassediagram geeft een schematische voorstelling van de Javaapplicatie. De klasse ‘converter’ is de main klasse en zal het sourcebestand inlezen en wegschrijven naar het gewenste targetbestand. In het klassediagram (nummer) zijn enkel de voornaamste attributen en methoden weergegeven. Voor een meer gedetailleerd overzicht wordt verwezen naar de digitale bijlage die men kan vinden bij dit onderzoek. Het klassediagram is getekend met het softwarepakket Visual Paradigm for UML. Dit softwareprogramma is gedownload als free trial voor 30 dagen via de website van Visual Paradigm42.

42

http://www.visual-paradigm.com/download/vpuml.jsp.

63

Figuur 16: UML klassediagram van de Java-applicatie Bron: eigen verwerking

Hieronder kan men iets meer uitleg vinden over de klassen van de Java-applicatie. Soms zijn enkele codefragmenten toegevoegd ter verduidelijking. De volledige code kan men raadplegen in de digitale bijlage. Als eerste wordt de klasse ‘converter’ nader toegelicht. Dit is de main klasse van de applicatie die een sourcebestand inleest en een targetbestand uitschrijft. In tabel 39 is de methode ‘public static void main’ uit de klasse weergegeven. Deze methode leest de commando’s uit het batchbestand één voor één in en voert ze uit. Het bestand begint steeds met een verwijzing

64

naar de locatie van de codebestanden. Daarna volgen twee regels die bepalen waar het sourcebestand te vinden is en naar waar het targetbestand weggeschreven moet worden. Een commando start met een Java-aanroep met als argumenten ‘converter’, ‘C:\Users\...’ (sourcebestand) en ‘C:\Users\... (targetbestand). Bij DXF en DXF2 volgt er nog een vierde argument, namelijk de verwijzing naar de template. In tabel 40 zijn de commando’s uit het batchbestand voor case 1a uitgeschreven. Er is geopteerd om met een batchbestand te werken omdat dit veel efficiënter is dan steeds de naam van het sourcebestand en targetbestand aan te passen in de code zelf. Het volledige batchbestand is te vinden in de digitale bijlage. Indien men dit bestand wenst te gebruiken dan moet het pad naar de bronbestanden aangepast worden.

Tabel 39: Methode public static void main uit de klasse converter Bron: eigen verwerking public static void main (String[] args) { try { if (args.length < 2) { System.out.println ("ERROR: Geef volledig pad en bestandsnamen om in te lezen en naar weg te schrijven, vb."+rn+"> Java converter sourcebestand targetbestand"); } else { sourcebestand=args[0]; targetbestand=args[1]; if(args.length>2) templatebestand=args[2]; leesBestand(sourcebestand); log(vo.toString()); schrijfBestand(targetbestand,templatebestand); } } catch (Exception e) { log(e.getClass().getSimpleName()+rn+e.getMessage()); } }

65

Figuur 17: Snapshot van het batchbestand Bron: eigen verwerking

Na het inlezen van een commando gaat de Java-applicatie in de main klasse na over welke extensie het gaat (via de methode ‘getFileExtension()’). Vervolgens wordt via de methode ‘leesBestand ()’ het bestandje ingelezen door de juiste klasse. Daarna zal de applicatie de extensie van het targetbestand bepalen en eveneens de juiste klasse oproepen om de ingelezen gegevens weg te schrijven volgens de syntax van het targetbestand. Hier volgt een voorbeeldcommando: ‘Java -cp . converter %source%/case1a.dxf %target%/case1a.gml’. Via de methode getFileExtension() zal de extensie van het sourcebestand (%source%/case1a.dxf) bepaald worden. In het voorbeeld gaat het om een DXF-bestand en wordt dus de klasse ‘dxf’ aangeroepen. In deze klasse wordt het bestandje ingelezen via de methode convertDxf2Adm() waar de nodige data weggeschreven worden naar een algemeen datamodel (Adm). Daarna zal op dezelfde wijze de extensie van het targetbestand (%target%/case1a.gml’) worden bepaald en de corresponderende klasse opgeroepen worden. De data in het algemeen datamodel wordt hier uitschreven volgens de syntaxregels van CityGML. Men kan het nieuwe bestand vinden op de opgegeven locatie. In dit onderzoek zijn alle targetbestanden opgeslagen in de map output

(C:\Users\Sarah\Desktop\CASES\Java_converter_application\build\output).

In

de

digitale bijlage kan men een readme bestand vinden waarin de werken van de applicatie duidelijk uitgelegd is.

Naast de main klasse bestaat er voor ieder onderzocht bestandsformaat een aparte klasse. Deze bevatten allen een methode om het bestand in te lezen en de data weg te schrijven naar het algemeen datamodel (convert…2Adm(), waarbij op de stippellijn de extensie komt van het sourcebestand) en een methode die de data uit het algemeen datamodel wegschrijft naar het nieuwe bestandsformaat (convertAdm2…(), waarbij op de stippellijn de extensie van het 66

targetbestand komt). Met uitzondering van de klasse ‘stl’, ‘dxf’ en ‘dxf2’ zijn dit de enige methodes in de klassen van de bestandsformaten. In de klasse ‘stl’ zal men ook de methode ‘trianguleer()’ terugvinden (tabel 40). Deze methode zorgt ervoor dat polygonen kunnen opgesplitst worden in driehoeken. De applicatie gebruikt deze methode steeds wanneer de data uit het algemeen datamodel moeten geconverteerd worden naar een STL-bestand. Dit moet gebeuren aangezien het formaat enkel driehoeken kan beschrijven. In figuur 18 kan men visueel waarnemen hoe de methode in zijn werk gaat. De methode zal eerst het aantal punten van een opgegeven vlak bepalen (regel 2). In regel 3 wordt een nieuwe arraylist aangemaakt waarin de nieuwe vlakken (driehoeken) opgeslagen worden. Men ziet eveneens op regel 3 dat het aantal driehoeken van een polygoon bepaald is door het aantal punten van de polygoon te verminderen met 2. In figuur 18 is een vlak met 5 punten weergegeven. Als men deze regel toepast wil dit zeggen dat het vlak bestaat uit 3 (=5-2) driehoeken. Dit is ook te zien in het voorbeeld. Het vlak bestaande uit punt 0,1,2, 3 en 4 wordt opgesplitst in drie driehoeken (0, 1, 2; 0, 2, 3 en 0, 3, 4). Regel 4 tot 6 zorgt ervoor dat er een waarschuwing naar de gebruiker wordt uitgeschreven wanneer er een vlak opgegeven wordt met minder dan 3 punten. Vanaf regel 7 worden de driehoeken bepaald. Om de werking hiervan uit te leggen is in tabel 41 het voorbeeld uit figuur 18 uitgeschreven.

Tabel 40: Trianguleer()-methode uit de klasse stl Bron: eigen verwerking

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

public static vlak[] trianguleer(vlak vl){ int nPunten = vl.size(); vlak[] va = new vlak[nPunten-2]; if(nPunten<3){ converter.log("Warning: twee punten zijn te weinig om een vlak te beschrijven"); } for(int i=2;i
67

Figuur 18: Visuele voorstelling van de opsplitsing van een polygoon in driehoeken Bron: eigen verwerking

Tabel 41: Uitwerking voorbeeld uit figuur 18 Bron: eigen verwerking Code met i gaande van 2 tot 4

Beschrijving

en nPunten = 5 In de arraylist ‘va’ wordt een nieuw vlak gecreëerd. i=2

for(int i=2;i<5;i++){ va[0]=new vlak(); va[0].add(vl.get(1)); va[0].add(vl.get(2)); va[0].add(vl.get(0)); }

Van het oorspronkelijke vlak ‘vl’ worden de coördinaten opgehaald van punt 1, punt 2 en punt 0. Deze punten bepalen de 1e driehoek.

Figuur 19: Aanduiding 1e driehoek Bron: eigen verwerking

68

In de arraylist ‘va’ wordt een tweede vlak gecreëerd. i=3



Figuur 20: Aanduiding 2e driehoek Bron: eigen verwerking In de arraylist ‘va’ wordt een derde vlak gecreëerd. i=4



Figuur 21: Aanduiding 3e driehoek Bron: eigen verwerking

Bij de opdeling van een vlak in driehoeken moet men dus een punt kiezen (hier 0) dat deel uitmaakt van elke driehoek. Vanuit dit punt worden alle driehoeken bepaald door middel van een lijn. Een vlak bestaande uit ‘n’ punten kan men altijd opdelen in ‘n-2’ driehoeken. Nadat

69

de methode ‘trianguleer()’ wordt aangeroepen in de methode ‘convertAdm2STL’ zal de conversie gewoon verder verlopen, analoog aan de andere bestandsformaten.

Bij het bestandsformaat DXF (nieuwe en oude versie) is geopteerd om te werken met een templatebestand. Dit is in principe ook mogelijk bij de andere formaten maar is hier sterk aanbevolen omdat het ASCII-bestand voor de beschrijving van een object al snel enkele pagina’s beslaat. Het templatebestand bevat de volledige beschrijving maar de veranderlijke delen worden via de methodes ‘getExtminExtmax()’ en ‘getSectionEntities()’ aangepast. Dankzij het templatebestand hoeft men niet de volledige tekst in de Java-applicatie uit te schrijven maar kan dit gewoon ingelezen worden (readDxftemplate()). In dit onderzoek zijn twee versies DXF-bestanden gebruikt aangezien de recente versie (2013) problemen levert bij het openen in diverse softwareprogramma’s, maar dit wordt verder besproken in 3.2. De templatebestanden worden mee opgegeven in het batchbestand.

3.2 Bespreking testcases na conversie met Java-applicatie

Alle cases zijn uitgevoerd met de zelfgeschreven Java-applicatie en hieronder besproken. Dit wil zeggen dat de sourcebestanden zijn ingevoerd in de applicatie en dat ze allemaal omgezet zijn naar de andere formaten. Een overzicht van deze testbestanden kan men vinden in tabel 37 van hoofdstuk 2. De resultaten zijn hieronder telkens per testcase afzonderlijk besproken. Alle sourcebestanden en targetbestanden zijn terug te vinden in de digitale bijlage.

Alvorens de cases afzonderlijk te evalueren wordt nog een algemene opmerking meegegeven. In de applicatie heeft men enkel de geometrische gegevens opgenomen in het algemeen datamodel. Andere informatie zoals kleur kan men dus niet converteren. Indien men toch wenst om kleuren of andere informatie mee te converteren dan zal de gebruiker ofwel de applicatie dienen bij te werken of de kleurinformatie na conversie manueel moeten invoegen. De eerste optie is niet eenvoudig wegens de verscheidenheid qua inhoud van de formaten. Stel dat men opteert om kleuren mee te converteren dan moet men voor ieder formaat in de desbetreffende klasse een methode voorzien die de kleur uit het sourcebestand haalt en wegschrijft volgens de regels van het targetbestand. Dit klinkt niet zo moeilijk maar als men de formaten nader bekijkt dan zal men merken dat kleurtoekenning niet op uniforme wijze geschiedt bij alle onderzochte formaten. Een ander probleem is dat men soms met texturen werkt in plaats van kleuren en deze bevinden zich vaak in andere bestanden of locaties. Indien 70

men ze wil gebruiken dan moet men op een correcte manier ernaar verwijzen. Indien het targetbestand deze wijze van toekennen niet ondersteunt dan kan deze eigenschap ook niet opgenomen worden na conversie. Omwille hiervan is geopteerd om in de Java-applicatie enkel geometrische gegevens op te nemen. Daar het voor de gebruiker wel interessant kan zijn om kleurinformatie in de bestanden op te nemen wordt hier aangeraden om te werken volgens optie 2. De nodige informatie om kleur op te nemen in de bestanden kan men raadplegen in hoofdstuk 2.

3.2.1 Case 1: DXF

Onderzoek naar het DXF-bestandsformaat maakt snel de complexiteit van het formaat duidelijk. De beschrijving van DXF is enorm uitgebreid en beslaat al snel meerdere pagina’s voor de definiëring van een eenvoudig object. Bovendien zorgen de verschillende versies voor veel diversiteit en problemen. In de loop der jaren is het bestandsformaat gewijzigd en steeds meer en meer uitgebreid om alle entiteiten te kunnen beschrijven. Men had eerst geopteerd om in dit onderzoek enkel te werken met versie DXF 2013 maar bij het analyseren van de resultaten heeft men besloten om ook een oudere versie te onderzoeken, om zodoende een vergelijking te kunnen maken. Het is duidelijk dat de recentste versie vaak niet te openen is in diverse programma’s terwijl een oude versie dit wel doet. In tabel 42 kan men zien met welke software de sourcebestanden succesvol gevisualiseerd worden. De R12/LT2 DXF versie opent in alle onderzochte programma’s en dit in tegenstelling tot DXF 2013. Dit komt omdat de vernieuwingen in deze laatste versie vaak nog niet ondersteund worden door deze softwareprogramma’s. Vooral Autodeskprogramma’s kunnen weg met de nieuwe versie maar ook het softwarepakket Free DWG Viewer. Deze testcase heeft dus twee sourcebestanden van waaruit geconverteerd wordt. De resultaten hiervan zijn te zien in tabel 43 en tabel 44. In het ene geval vertrekt men van een DXF-file versie 2013. In het tweede geval wordt een DXF-file versie R12/LT2 gebruikt. De geometrieën uit deze sourcebestanden bevatten geen kleuren of materialen.

71

Tabel 42: Overzicht van softwareprogramma’s waarin men de DXF-sourcebestanden kan visualiseren (DXF uit case a en DXF2 uit case b) Bron: eigen verwerking Softwareprogramma

case1a.dxf

case1b.dxf

Autodesk 3ds Max Autodesk Civil 3D Autodesk Design Review Autodesk Maya DWG TrueView Free DWG Viewer SketchUp SolidWorks E-Drawings Trimble Realworks Viewer Geomatic Spark Tabel 43: Overzicht van softwareprogramma’s waarin men de targetbestanden kan visualiseren (case 1a) Bron: eigen verwerking DXF

DXF2

OFF

GML

OBJ

STL

X3D

PLY

VRML

X3DV

XYZ

Autodesk 3ds Max Autodesk Civil 3D Autodesk Design Review Autodesk Maya BS Contact CCViewer CloudCompare Cortona 3D Viewer DWG TrueView FZK Viewer Flux Studio Free DWG Viewer Free WRL Launcher Geomatic Spark

72

GML Viewer Leica Cyclone MeshLab SketchUp SolidWorks E-Drawings Trimble Realworks Viewer

In bovenstaande tabel is te zien dat hier en daar sommige targetbestanden niet willen openen. Bij het DXF-bestand komt in dit geval steeds de melding ‘invalid file version’ tevoorschijn. De programma’s waar het STL-bestand niet wil laden geven de melding: ‘invalid file’. Het valt ook op dat het X3DV-bestand enkel wil openen in MeshLab, in de andere gevallen spreekt men van ‘illegal file format’ of ‘unknown file type’ terwijl de programma’s normaliter een X3DV-extensie moeten openen. Het PLY-formaat geeft de melding ‘Mesh is not triangular’ in CCViewer en CloudCompare. In deze programma’s worden enkel de punten gevisualiseerd. Daarentegen opent het bestand perfect

in MeshLab. Verder kan men

opmerken dat voor de visualisatie in MeshLab en FluxStudio de extensie .vrml moet omgezet worden naar .wrl om visualisatie mogelijk te maken. Dit is ook zo bij de andere testcases maar zal men verder in dit onderzoek niet meer vernoemen. De andere targetbestanden openen perfect in alle onderzochte programma’s. De resultaten van de DXF-targetbestanden zijn enigszins te verwachten. De software die deze bestanden na conversie opent is dezelfde als deze vóór de conversie (tabel 42). Tabel 44: Overzicht van softwareprogramma’s waarin men de targetbestanden kan visualiseren (case 1b) Bron: eigen verwerking DXF

DXF2

OFF

GML

OBJ

STL

X3D

PLY

VRML

X3DV

XYZ

Autodesk 3ds Max Autodesk Civil 3D Autodesk Design Review Autodesk Maya BS Contact CCViewer CloudCompare

73

Cortona 3D Viewer DWG TrueView FZK Viewer Flux Studio 2.1 Free DWG Viewer Free WRL Launcher Geomatic Spark GML Viewer Leica Cyclone MeshLab SketchUp SolidWorks E-Drawings Trimble Realworks Viewer

De resultaten in tabel 44 zijn identiek aan die in tabel 43. Hieruit kan men concluderen dat het niet uitmaakt welke versie het DXF-sourcebestand heeft aangezien de resultaten na conversie identiek zijn. Het verschil is dat men bij de visualisatie van het sourcebestand meer keuze heeft aan softwareprogramma’s omdat de nieuwe versie vaak nog niet is ondersteund. De resultaten na conversie zijn identiek maar DXF-bestanden van de oudere versie zullen, net zoals voorheen, door veel meer programma’s ondersteund worden.

3.2.2 Case 2: OFF

In case 2 wordt een kubus in OFF-formaat geconverteerd. Het OFF-formaat wordt slechts door weinig software ondersteund ondanks zijn vrij eenvoudige opbouw. Alle conversies lukken zonder enig probleem al kan men hier weer opmerken dat de conversie naar het DXFformaat geen groot succes is. Enkel het programma Free DWG Viewer kan het targetbestandje openen en weergeven. In alle andere gevallen krijgt men de melding: “invalid file version”. Daarentegen zorgt de conversie naar de oudere versie voor geen enkel probleem. Net zoals in case 1 geven STL, PLY en X3DV dezelfde foutmeldingen in dezelfde programma’s. Ondanks deze foutmeldingen wordt elk targetbestand in minstens 1 viewer gevisualiseerd en correct weergegeven.

74

Tabel 45: Overzicht van softwareprogramma’s waarin men het OFF-sourcebestand kan visualiseren Bron: eigen verwerking Softwareprogramma

case2.off

MeshLab Tabel 46: Overzicht van softwareprogramma’s waarin men de targetbestanden kan visualiseren (case 2) Bron: eigen verwerking DXF

DXF2

OFF

GML

OBJ

STL

X3D

PLY

VRML

X3DV

XYZ

Autodesk 3ds Max Autodesk Civil 3D Autodesk Design Review Autodesk Maya BS Contact CCViewer CloudCompare Cortona 3D Viewer DWG TrueView FZK Viewer Flux Studio Free DWG Viewer Free WRL Launcher Geomatic Spark GML Viewer Leica Cyclone MeshLab SketchUp SolidWorks E-Drawings Trimble Realworks Viewer

75

3.2.3 Case 3: CityGML

Het huis uit case 3 is na conversie nog steeds in alle formaten te visualiseren. Het resultaat is wel enigszins anders omdat de extra informatie zoals de kleur en andere materialen bij conversie verloren zijn gegaan. Ook in deze case kan men dezelfde opmerking maken wat betreft het DXF-formaat. De nieuwe versie opent slechts met 1 programma terwijl dit voor de oude versie opnieuw met alle beschikbare programma’s gevisualiseerd wordt.

Tabel

47: Overzicht

van

softwareprogramma’s

waarin

men

het CityGML-

sourcebestand kan visualiseren Bron: eigen verwerking Softwareprogramma

case3.gml

FZKViewer GML Viewer Tabel 48: Overzicht van softwareprogramma’s waarin men de targetbestanden kan visualiseren (case 3) Bron: eigen verwerking DXF

DXF2

OFF

GML

OBJ

STL

X3D

PLY

VRML

X3DV

XYZ

Autodesk 3ds Max Autodesk Civil 3D Autodesk Design Review Autodesk Maya BS Contact CCViewer CloudCompare Cortona 3D Viewer DWG TrueView FZK Viewer Flux Studio Free DWG Viewer Free WRL Launcher Geomatic Spark

76

GML Viewer Leica Cyclone MeshLab SketchUp SolidWorks E-Drawings Trimble Realworks Viewer

3.2.4 Case 4: OBJ

De theepot uit case 4 is eveneens naar alle formaten geconverteerd. In tegenstelling tot de vorige case, waar de resultaten gelijkaardig zijn, valt hier op dat het DXF2-targetbestand niet meer kan geopend worden in de Autodesk programma’s. Bij het openen van het PLYtargetbestand in CCViewer en CloudCompare blijft de foutmelding (‘mesh is not triangular’) achterwege. Alle andere resultaten zijn dezelfde als in voorbije cases. De theepot uit deze case bezit geen kleurinformatie, dus de visualisatiekenmerken zijn afhankelijk van de gebruikte programma’s. In tegenstelling tot de vorige cases is de looptijd van de applicatie een stuk langer. Dit komt doordat het aantal punten en vlakken veel groter is in tegenstelling tot vorige bestanden. Hierover kan men ook opmerken dat de conversie naar DXF (oude en nieuwe versie) het langste duurt. Dit is enigszins te verwachten gezien de uitgebreide beschrijving en de grootte van de bestanden (tabel 65). Het XYZ-targetbestand wordt het snelste gegenereerd aangezien het enkel punten bevat. Tabel 49: Overzicht van softwareprogramma’s waarin men het OBJ-sourcebestand kan visualiseren Bron: eigen verwerking Softwareprogramma

case4.obj

Autodesk 3ds Max Autodesk Maya CCViewer CloudCompare MeshLab Geomatic Spark

77

Tabel 50: Overzicht van softwareprogramma’s waarin men de targetbestanden kan visualiseren (case 4) Bron: eigen verwerking DXF

DXF2

OFF

GML

OBJ

STL

X3D

PLY

VRML

X3DV

XYZ


3.2.5 Case 5: STL

De resultaten na conversie van de ster in het STL-sourcebestand zijn identiek aan die uit case 4. Wanneer men een STL-sourcebestand met de applicatie converteert dan zal men telkens een conversie uitvoeren van een aantal driehoeken aangezien het object hier opgebouwd wordt uit driehoeken. Hierdoor hebben de targetbestanden allemaal meer polygonen in hun bestand zitten.

78

Tabel 51: Overzicht van softwareprogramma’s waarin men het STL-sourcebestand kan visualiseren Bron: eigen verwerking Softwareprogramma

case5.stl

Autodesk 3ds Max Autodesk Maya MeshLab SolidWorks E-Drawings Geomatic Spark Tabel 52: Overzicht van softwareprogramma’s waarin men de targetbestanden kan visualiseren (case 5) Bron: eigen verwerking DXF

DXF2

OFF

GML

OBJ

STL

X3D

PLY

VRML

X3DV

XYZ

Autodesk 3ds Max Autodesk Civil 3D Autodesk Design Review Autodesk Maya BS Contact CCViewer CloudCompare Cortona 3D Viewer DWG TrueView FZK Viewer Flux Studio Free DWG Viewer Free WRL Launcher Geomatic Spark GML Viewer Leica Cyclone MeshLab SketchUp SolidWorks E-Drawings

79


3.2.6 Case 6: X3D (a) en X3DV (b)

Evenals het DXF-formaat vormt dit bestandsformaat een grote uitdaging om alle mogelijkheden te kennen. De enorme hoeveelheid aan mogelijkheden om objecten te beschrijven maar ook de vele uitbreidingen maken het niet gemakkelijk om een goede converter-applicatie te schrijven. Omdat een volledige opname van alle mogelijkheden in de applicatie zodanig uitgebreid zou zijn is hier geopteerd om de basis te implementeren. Op deze wijze is het mogelijk om de objecten van alle andere bestandsformaten te converteren naar X3D of X3DV. De resultaten hiervan kan men met diverse programma’s bekijken (zie cases 1-5 en 7-9). Met de ‘basis’ bedoelt men dat er geopteerd is om te werken met de IndexedFaceSet node. Deze node definieert een reeks coördinaten en vlakken waardoor alle mogelijke vormen gecreëerd kunnen worden. Men kan zich afvragen waarom de basis shape nodes niet geïmplementeerd zijn. De verklaring hiervoor is dat de beschrijving van deze nodes moeilijk kan omgezet worden naar coördinaten en vlakken. Hoe kan men een cilinder met een bepaalde hoogte en straal converteren naar afzonderlijke vlakken met coördinaten? Hiervoor zou men een algoritme moeten schrijven die de basic shape node opdeelt in afzonderlijke vlakken, maar hierdoor zou men in het onderzoek te ver afdwalen.

Als men wil starten met een X3D/X3DV-bestand dan zal de conversie perfect lukken indien het object in het sourcebestand beschreven is volgens de basis die geïmplementeerd is in de Java-applicatie. Soms is dit niet het geval en gebruikt men uitgebreide beschrijvingen om objecten te definiëren. Natuurlijk rijst de vraag hoe men dit kan oplossen. In dit onderzoek heeft men in deze gevallen gebruik gemaakt van een tussenstap met behulp van MeshLab. In MeshLab kan men het X3D/X3DV-sourcebestand openen en exporteren naar een PLYbestand. Het gegenereerde PLY-bestand kan nu als sourcebestand gebruikt worden in de applicatie en desgewenst naar andere formaten geconverteerd worden.

In deze case is men op zoek gegaan naar een X3D- en X3DV-bestand waarin er meer informatie voorkomt dan de beschreven basiselementen uit de applicatie. Op deze manier kan men aantonen dat het gebruik van een tussenstap eveneens goede resultaten levert. Bovendien kan iedereen deze tussenstap maken aangezien MeshLab gratis te downloaden is via het

80

internet. Het X3D- en X3DV-bestand bevatten hetzelfde object (vrouw) maar beschrijven dit elk volgens hun eigen syntax. De targetbestanden geven hetzelfde resultaat (tabel 55 en tabel 56). Bovendien kan men ze ook vergelijken met de resultaten uit tabel 58 en deze uit case 4 en 5. Deze resultaten zijn allen identiek. Tabel 53: Overzicht van softwareprogramma’s waarin men het X3D- en X3DVsourcebestand kan visualiseren Bron: eigen verwerking Softwareprogramma

case6a.x

case6b.x3dv

BS Contact Flux Studio Free WRL Launcher MeshLab In tabel 53 kan men een overzicht vinden van de softwareprogramma’s waarin de sourcebestanden kunnen ingeladen worden. Deze bestanden bevatten heel wat informatie die men in alle programma’s uit bovenstaande tabel kan waarnemen met uitzondering van MeshLab. Dit kan misleidend zijn wanneer men dergelijk bestand enkel in MeshLab zou openen. Daarom is het steeds aan te raden meerdere viewers te raadplegen en het bestandje zelf te openen in een teksteditor (bv. WordPad). Zo kan de gebruiker nagaan of het sourcebestand informatie bevat die niet wordt weergegeven/ geconverteerd is. Achteraf kan men deze informatie, indien gewenst, opnieuw toevoegen. Tabel 54: Overzicht van softwareprogramma’s waarin men de PLY-sourcebestanden kan visualiseren Bron: eigen verwerking Softwareprogramma

case6a.ply

case6b.ply

CCViewer CloudCompare MeshLab Geomatic Spark

81

De kleurinfo na conversie van X3D/X3DV naar PLY in MeshLab is bewaard maar kan men niet waarnemen in bovenstaande programma’s. Na het openen van het bestand in een teksteditor ziet men dat deze info niet verloren is maar dat dit wel het geval is na conversie. Tabel 55: Overzicht van softwareprogramma’s waarin men de targetbestanden kan visualiseren (case 6a) Bron: eigen verwerking DXF

DXF2

OFF

GML

OBJ

STL

X3D

PLY

VRML

X3DV

XYZ


82

Tabel 56: Overzicht van softwareprogramma’s waarin men de targetbestanden kan visualiseren (case 6b) Bron: eigen verwerking DXF

DXF2

OFF

GML

OBJ

STL

X3D

PLY

VRML

X3DV

XYZ


3.2.7 Case 7: PLY

De lantaarn uit deze case bevat geen kleurinformatie maar wel verschillende geometrische vormen die allemaal gecreëerd worden door afzonderlijke vlakken. De conversie met de applicatie gebeurt op dezelfde manier als de case hierboven en geeft dezelfde resultaten. Het PLY-targetbestand opent nog steeds in dezelfde programma’s zoals het sourcebestand.

83

Tabel 57: Overzicht van softwareprogramma’s waarin men het PLY-sourcebestand kan visualiseren Bron: eigen verwerking Softwareprogramma

case7.ply

CCViewer CloudCompare MeshLab Geomatic Spark Tabel 58: Overzicht van softwareprogramma’s waarin men de targetbestanden kan visualiseren (case 7) Bron: eigen verwerking DXF

DXF2

OFF

GML

OBJ

STL

X3D

PLY

VRML

X3DV

XYZ


84

3.2.8 Case 8: VRML/WRL

Aangezien VRML de voorloper is van X3D vormt zich hier ook het probleem van de tamelijk uitgebreide beschrijving van het formaat. Net zoals bij X3D/X3DV heeft men geopteerd om in de applicatie enkel de basiselementen op te nemen (IndexedFaceSet, zie 3.2.8). Het zal er in dit geval dus van afhangen welke inhoud het VRML sourcebestand beschrijft. Indien het object beschreven is door basiselementen dan zal rechtstreeks conversie mogelijk zijn. In het andere geval zal men moeten werken zoals in case 6 (3.2.6) en gebruik maken van de tussenstap.

In deze case is geopteerd om een sourcebestand te kiezen dat niet kan ingelezen worden met de applicatie. Men moet het bestand in MeshLab openen43 en op dezelfde manier als X3D/X3DV (2.3.6) omzetten naar het PLY-formaat. Na deze conversie ontstaat het PLY sourcebestand dat op zijn beurt met de applicatie omgezet wordt. De resultaten kan men raadplegen in tabel 61. Bij het bekijken ervan vallen geen nieuwigheden op. Tabel 59 geeft een overzicht van de softwareprogramma’s waarin men het VRMLsourcebestand kan bekijken. Bij het openen van dit bestand zal de gebruiker een schip te zien krijgen met bepaalde kleurdefinities en een bepaalde shininess. Door het toekennen van deze eigenschappen lijkt het schip veel reëler. Na de omzetting naar PLY in MeshLab gaat deze informatie niet verloren, maar wordt ze omgezet naar de RBG-codering die eigen is aan het PLY-formaat. Het is belangrijk daarbij te vermelden dat de kleuren in het originele VRMLbestand een RGB-waarde hebben tussen 0 en 1 maar dat dit in het PLY-bestand waarden zijn variërend tussen 0 en 255. De shininess waarden uit het VRML-bestand wordt vertaald als de transparantiegraad in het PLY-formaat. Dit is echter een foute interpretatie want de shininess is niet gelijk aan de transparantiegraad. In het VRLM-sourcebestand van deze case is geen transparency gedefinieerd. Indien men het VRML-sourcebestand bekijkt in bijvoorbeeld MeshLab en dit vergelijkt met de weergave van het PLY-bestand dan zal men geen verschil merken. Het is wel zo dat de visualisatie afhankelijk is van viewer tot viewer. Het openen van het PLY-bestand in bijvoorbeeld CCViewer geeft een ander resultaat qua kleuren. Het is niet zo dat er een totaal andere kleur wordt weergegeven maar de weergave is niet identiek. Bovendien is de glans die men wel ziet bij het VRML-bestand (behalve in MeshLab) niet

43

Om het VRML-bestand in MeshLab te openen moet men de extensie veranderen naar WRL.

85

meer waar te nemen wanneer men het PLY-bestand visualiseert. Dit wil zeggen dat deze parameters niet of verkeerd opgenomen zijn in het nieuwe bestand. In tabel 62 en tabel 63 is kleur toegekend volgens de VRML- en PLY-syntax. De omzetting gebeurt als volgt: 

men neemt de waarden van de diffuseColor (tabel 62);



aangezien in PLY de RGB-waarden tussen 0 en 255 liggen moet men de waarde omrekenen (regel van drie). Enkel het getal voor de komma wordt opgenomen, men houdt dus geen rekening met afrondingen Bijvoorbeeld: ‘diffuseColor 0.086275 0.027451 0.007843’ in VRML wordt ‘22 7 1’ in PLY (255x0.086275 = 22.000125; 255x0.027451= 7.000005; 255x0.007843= 1.999965);



naast een RGB waarde wordt ook een transparantiegraad meegegeven in het PLYbestand. Deze waarde neemt men over van de shininess waarde uit het VRML maar dit is echter een foute interpretatie. De omzetting gebeurt op dezelfde wijze (255x1= 255);



de omgerekende waarde kan men dan plaatsen achter de desbetreffende punten in de vertexlist van het PLY-bestand.

Zoals reeds vermeld zal de kleurinformatie uiteindelijk niet opgenomen worden in de targetbestanden vanwege de applicatie. Maar net zoals bij de andere bestanden kan men deze informatie terug toevoegen na conversie. Vandaar de uitgebreide uitleg in hoofdstuk 2 en de opmerking hierboven. De resultaten van de conversie zijn bevredigend, in dat opzicht dat alle conversies geslaagd zijn en men ze met minstens 1 softwarepakket kan visualiseren. Tabel 59: Overzicht van softwareprogramma’s waarin men het VRML-sourcebestand kan visualiseren Bron: eigen verwerking Softwareprogramma

case8.vrml

BS Contact Cortona 3D Viewer Flux Studio 2.1 Free WRL Launcher MeshLab

86

Tabel 60: Overzicht van softwareprogramma’s waarin men het OFF-sourcebestand kan visualiseren Bron: eigen verwerking Softwareprogramma

case8.ply

CCViewer CloudCompare MeshLab Geomatic Spark Tabel 61: Overzicht van softwareprogramma’s waarin men de targetbestanden kan visualiseren (case 8) Bron: eigen verwerking DXF

DXF2

OFF

GML

OBJ

STL

X3D

PLY

VRML

X3DV

XYZ


87

Tabel 62: Kleurinformatie VRML-bestand (fragment sourcebestand case8.vrml) Bron: eigen verwerking … DEF H Transform { children Shape { appearance Appearance { material DEF Cm Material { ambientIntensity 0.084655 diffuseColor 0.086275 0.027451 0.007843 specularColor 0.129412 0.129412 0.078431 shininess 1 } } geometry IndexedFaceSet { coord Coordinate { point [ -0.192106 -26.815193 -1.955093, 0.000354 -12.263679 -11.362326, -0.38709 -12.353559 -11.495284, 0.000736 -26.770454 -1.888916, -0.1921 -27.031179 -2.274632, -0.547571 -12.570536 -11.816281, -0.387079 -12.787503 -12.137279, -0.271982 -26.923189 -2.114862, 0.19358 -26.815182 -1.955093, 0.387804 -12.353538 -11.495284, 0.000744 -27.075909 -2.340809, 0.000371 -12.877365 -12.27024, 0.273461 -26.923174 -2.114862, 0.548295 -12.570507 -11.816281, 0.193586 -27.031168 -2.274632, 0.387815 -12.787482 -12.137279, ] } creaseAngle 1 solid FALSE coordIndex [ 0,1,2,-1,0,3,1,-1,4,5,6,-1,4,7,5,-1,1,8,9,-1,1,3,8,-1,7,2,5,-1,7,0,2,-1,10,6,11,-1,10,4,6,1,9,12,13,-1,9,8,12,-1,4,0,7,-1,4,3,0,-1,10,3,4,-1,10,8,3,-1,14,8,10,-1,14,12,8,-1,15,10,11,-

88

1,15,14,10,-1,13,14,15,-1,13,12,14,-1,2,6,5,-1,1,6,2,-1,1,11,6,-1,9,11,1,-1,9,15,11,-1,9,13,15,1,] } } } …

Tabel 63: Kleurinformatie PLY-bestand (fragment PLY-bestand na omzetting in MeshLab) Bron: eigen verwerking ply format ascii 1.0 comment VCGLIB generated element vertex 2923 property float x property float y property float z property uchar red property uchar green property uchar blue property uchar alpha element face 5110 property list uchar int vertex_indices end_header -0.002893 -2.11483 26.8262 22 7 1 255 0.189567 -11.5221 12.2747 22 7 1 255 -0.197877 -11.655 12.3646 22 7 1 255 0.189949 -2.04865 26.7815 22 7 1 255 -0.00288701 -2.43437 27.0422 22 7 1 255 -0.358358 -11.976 12.5816 22 7 1 255 -0.197866 -12.297 12.7985 22 7 1 255 -0.082769 -2.2746 26.9342 22 7 1 255 0.382793 -2.11483 26.8262 22 7 1 255 0.577017 -11.655 12.3646 22 7 1 255 0.189957 -2.50055 27.0869 22 7 1 255 0.189584 -12.43 12.8884 22 7 1 255 0.462674 -2.2746 26.9342 22 7 1 255 0.737508 -11.976 12.5815 22 7 1 255 0.382799 -2.43437 27.0422 22 7 1 255 0.577028 -12.297 12.7985 22 7 1 255 …

89

3.2.9 Case 9: XYZ

De laatste testcase in dit onderzoek bevat de puntenwolk van een kubus zonder enige kleurinformatie. Door het gebrek aan vlakkeninformatie is het niet mogelijk om dit formaat te converteren via de applicatie. In onderstaande tabel is een overzicht te vinden van de softwareprogramma’s waarin het sourcebestand kan worden gevisualiseerd. Tabel 64: Overzicht van softwareprogramma’s waarin men het XYZ-sourcebestand kan visualiseren Bron: eigen verwerking Softwareprogramma

case10.xyz

CCViewer CloudCompare MeshLab Leica Cyclone

Dit bestandsformaat is echter wel van belang in dit onderzoek omdat men van alle andere formaten naar XYZ kan overgaan. 3.3 Algemene conclusie targetbestanden en softwareprogramma’s

Als men het totaalpakket bekijkt dan kan men tevreden zijn over de werking van de Javaapplicatie. Alle conversies worden goed uitgevoerd. De resultaten na conversie kunnen in minimum één softwarepakket bekeken worden en het object blijft gelijk na conversie.

In tabel 65 zijn de gemiddelde bestandsgroottes weergegeven van alle targetbestanden in dit onderzoek. Deze resultaten zijn telkens het gemiddelde van de targetbestanden van hetzelfde type. Men kan daarbij de opmerking maken dat de beschreven objecten in de cases nogal verschillen. Maar desondanks zijn de gemiddelden in tabel 65 representatief aangezien de vergelijking gebeurt voor dezelfde cases. Als men de targetbestanden zou evalueren qua grootte dan ziet men een verwacht resultaat. Het DXF (2013)-bestand staat op kop. Dit is niet te verwonderen gezien de uitgebreide beschrijving. Daarna volgen CityGML (1721 kB), DXF (R12/LT2), X3D (488 kB) en X3DV (447 kB). Logischer wijze zou men verwachten dat VRML hierachter komt aangezien dit type de voorloper is van X3D en er dus goed op lijkt 90

qua inhoud en opbouw. Toch is dit niet het geval en komt STL hier tussenin. Bovendien is er een aanzienlijk verschil tussen de groottes van de STL (371 kB) – en VRML (132kB)testcases (factor ± 3). De verklaring hiervoor is dat een STL-bestand de gegevens steeds herhaalt aangezien er geen topologische relaties aanwezig zijn. Bovendien zijn er enkel driehoeken gedefinieerd waardoor er meer vlakken beschreven worden dan in de andere formaten. Tot slot volgen OFF (87 kB), OBJ (75 kB), PLY (73 kB) en XYZ (32 kB). Men kan zich afvragen of er een verband bestaat tussen de mogelijkheden die een formaat biedt en de bestandsgrootte. Omwille hiervan is in tabel 65 de inhoud van het formaat opgenomen. Men kan concluderen dat de formaten die de meeste mogelijkheden bieden zich bovenaan de lijst bevinden. In de top 7 staan, met uitzondering van STL, allemaal formaten die naast geometrie en kleur ook nog tal van andere eigenschappen kunnen opnemen. De positie van STL is hier wel opmerkelijk aangezien het formaat enkel de geometrie opneemt. Zoals hierboven is aangehaald komt dit doordat de gegevens dubbel beschreven worden en enkel driehoeken gedefinieerd zijn. Het bestand dient bijgevolg veel meer vlakken te beschrijven dan de overige formaten. De eenvoudige formaten OBJ, PLY, OFF en XYZ sluiten de lijst af aangezien ze enkel de geometrie en kleureigenschappen kunnen bevatten. Men dient wel te vermelden dat in dit onderzoek nergens kleurinformatie is opgenomen na conversie. Deze factor speelt bij de rangschikking in tabel 65 dus geen rol. Er bestaat dus wel degelijk een verband tussen de bestandsgrootte en de mogelijkheden binnen een formaat.

Tabel 65: Gemiddelde bestandsgrootte van de targetbestanden en beschrijving inhoud Bron: eigen verwerking Type targetbestand DXF (2013)

Bestandsgrootte (kB) 2085

Inhoud formaat alle mogelijke geometrie + kleureigenschappen/materiaaldefinities + tal van andere eigenschappen (enorm uitgebreide beschrijving)

CityGML

1721

=applicatieschema geïmplementeerd in GML3 geometrie + kleureigenschappen/materiaaldefinities + gebruik van XML-schema’s + tal van andere eigenschappen

91

DXF (R12/LT2)

1110

geometrie + kleureigenschappen/materiaaldefinities + tal van andere eigenschappen (Opgelet: is beperkter in beschrijving dan DXF 2013 en zal sommige entiteiten niet bevatten)

X3D

X3DV

488

geometrie (basic shape nodes + advanced nodes) + kleurdefinitie/materiaaleigenschappen + tal van andere mogelijkheden

X3D

447

geometrie (basic shape nodes + advanced nodes) + kleurdefinitie/materiaaleigenschappen + gebruik van XML-schema’s + tal van andere mogelijkheden

STL

371

geometrie beschreven aan de hand van driehoeken

VRML

132

geometrie (basic shape nodes + advanced nodes) + kleurtoekenning/materiaaleigenschappen + tal van andere eigenschappen

OFF

87

geometrie + kleurdefinitie

OBJ

75

geometrie + kleureigenschappen/materiaaldefinities mogelijk via materiaalbibliotheek + andere eigenschappen

PLY

73

geometrie + kleureigenschappen/materiaaldefinities

XYZ

32

geometrie (enkel punten) + kleurdefinitie

In tabel 66 kan men de bestandsgrootte vinden van de sourcebestanden. Men mag deze niet met elkaar vergelijken aangezien ze een verschillende inhoud hebben en dus niet op deze basis te vergelijken zijn. Het DXF-bestand beschrijft bijvoorbeeld twee vlakken, terwijl het PLY-bestand zo’n 8828 vlakken definieert om tot een object te komen. Deze tabel is

92

opgenomen met het oog een vergelijking te maken tussen DXF 2013 en DXF R12/LT2 en tussen X3D en X3DV. Deze vergelijking is gerechtvaardigd aangezien de bestanden hetzelfde object beschrijven.

Het verschil in bestandsgrootte tussen DXF 2013 en DXF R12/LT2 is groot. Dit kan één van de redenen zijn om te opteren voor DXF R12/LT2. Natuurlijk moet men er zich van vergewissen dat DXF R12/LT2 beperkter is in zijn mogelijkheden. Het is dus afhankelijk van de toepassing om al dan niet te opteren voor DXF R12/LT2. Een andere reden om hier voor de oude versie te kiezen is dat deze in alle onderzochte programma’s opent. Zowel vóór conversie als na conversie is het aantal programma’s waarin het bestand opent groter. Tussen X3D en X3DV is geen verschil te bespeuren qua bestandsgrootte dus de keuze zal geen invloed hebben op de bestandsgrootte. Indien men met alle facetten rekening houdt krijgt X3D de voorkeur aangezien X3DV in sommige softwareprogramma’s niet opent. Verder kan men ook afleiden dat de conversie van X3D en X3DV naar PLY de bestandsgrootte doet afnemen. Hiervoor is een plausibele verklaring, namelijk het verlies aan informatie. In navolging van het vorige zou men verwachten dat het resultaat van de conversie van VRML naar PLY (3.2.8) ook een verkleining in bestandsgrootte zou teweegbrengen. Niets is minder waar, in tegendeel de bestandsgrootte neemt enorm toe. De reden hiervoor is iets moeilijker te achterhalen. Een eerste mogelijke verklaring is dat de toekenning van de kleuren in PLY aan ieder punt afzonderlijk gebeurt, terwijl het VRML-bestand een bepaald materiaal toekent aan een reeks punten ( = minder herhaling) maar dit is ook het geval bij X3D en X3DV. Een andere reden, die meer steek houdt is het verschil in aantal faces. In de VRML-case bevat het PLY-bestand maar liefst 5110 vlakken, terwijl dit in de X3D/X3DV-case slechts 1640 vlakken zijn. Bovendien is het verschil in aantal vertexen zo’n 1000 punten. Zowel het OFFals XYZ-bestand beschrijven beiden een kubus. Omdat dit een eenvoudige vorm is die door 8 punten beschreven is in XYZ en door 8 punten en 6 vlakken in OFF, is de bestandsgrootte slechts 1 kB. In tabel 66 kan men zien dat PLY het grootste sourcebestand is. Dit komt omdat voor de beschrijving van de lantaarnpaal 4440 punten en 8828 vlakken nodig zijn. Als men kijkt naar alle targetbestanden van dit onderzoek dan zal men zien dat de bestanden uit case 7 (PLY, 3.2.7) allen groter zijn dan de targetbestanden uit de andere cases.

93

Tabel 66: Bestandsgrootte van de sourcebestanden Bron: eigen verwerking Type sourcebestand

Bestandsgrootte (kB)

PLY

281

OBJ

216

VRML

162

omzetting naar PLY

201

DXF (2013)

140

X3D

97

omzetting naar PLY

94

X3DV

97

omzetting naar PLY

94

STL

12

DXF (R12/LT2)

9

CityGML

9

OFF

1

XYZ

1

Na het vergelijken van de source – en targetbestanden hierboven, kan men hieronder de resultaten lezen van de geteste softwareprogramma’s. In tabel 38 (hoofdstuk 2) kan men zien welk softwareprogramma het meest aantal onderzochte formaten kan openen. Het is al snel duidelijk dat MeshLab hier de bovenhand neemt. Met uitzondering van DXF en CityGML opent dit programma alle formaten en steeds met goede resultaten. Ook Geomatic Spark ondersteunt een viertal formaten uit dit onderzoek, namelijk DXF, STL, OBJ en PLY. Natuurlijk is er gewerkt met een ruim aantal softwarepakketten om zodoende een vergelijking mogelijk te maken. In onderstaande tabel volgt een overzicht van het aantal failures bij elk softwarepakket. Een failure houdt in dat men het targetbestand niet kan openen. In dat geval geeft het programma een foutmelding, komt er niets tevoorschijn of sluit het programma af. Dit laatste treedt enkel op bij DXF 2013-bestanden in sommige softwareprogramma’s. In de meeste gevallen krijgt de gebruiker gewoon een foutmelding te lezen.

94

Tabel 67: Aantal failures bij het openen van de targetbestanden in de onderzochte softwareprogramma’s Bron: eigen verwerking Softwarepakket

Aantal failures (totaal)

Werking programma (%)

Cortona 3D Viewer

0 (10)

100.0

FZK Viewer

0 (10)

100.0

Free DWG Viewer

0 (20)

100.0

GML Viewer

0 (10)

100.0

Leica Cyclone

0 (10)

100.0

MeshLab

0 (80)

100.0

CCViewer

4 (30)

86.7

CloudCompare

4 (30)

86.7

Geomatic Spark

10 (50)

80.0

BS Contact

10 (30)

66.7

Flux Studio

10 (30)

66.7

Free WRL Launcher

10 (30)

66.7

SolidWorks E-Drawings

10 (30)

66.7

SketchUp

10 (20)

50.0


10 (20)

50.0

Autodesk 3ds Max

24 (40)

40.0

Autodesk Maya

24 (40)

40.0

Autodesk Civil 3D

14 (20)

30.0

Autodesk Design Review

16 (20)

20.0

DWG TrueView

16 (20)

20.0

In tabel 38 (hoofdstuk 2) kan men nagaan welk type software gebruikt is in dit onderzoek. Men zal bemerken dat zowel freeware, free trials en commerciële software zijn aangewend met het oog op een mogelijke vergelijking.

Uit tabel 68 kan men besluiten dat Cortona 3D Viewer , FZK Viewer, Free DWG Viewer, GML Viewer, Leica Cyclone en MeshLab alle mogelijke targetbestanden inlezen. Dit wil zeggen dat indien het programma het formaat van het targetbestand ondersteunt, dit programma het bestand ook na conversie zal inlezen en visualiseren. Tussen deze 5

95

programma’s vindt men 4 freeware programma’s en 1 commercieel, namelijk Leica Cyclone. Indien men de resultaten kritisch benadert dan zijn er hier en daar toch enkele bedenkingen. Zo neemt men de resultaten bij softwareprogramma’s waar DXF ondersteund wordt best met een korreltje zout aangezien de DXF 2013-versie door weinig programma’s herkend wordt. Vooral de Autodesk programma’s44 scoren slecht. Indien men in de resultaten geen rekening zou houden met DXF 2013 dan zouden vele programma’s hoger scoren. Men zou verwachten dat de commerciële programma’s zich bovenaan de lijst bevinden omdat deze software door professionals is ontwikkeld en geüpgraded wordt. In dit onderzoek is dit, met uitzondering van Leica Cyclone, niet het geval. Dit resultaat wordt sterk beïnvloed door het gebruik van DXF 2013. Het pakket Leica Cyclone gebruikt men hier enkel om de XYZ-bestanden in te laden en te visualiseren. In principe kan er weinig verkeerd gaan met dit type bestand. De resultaten van de testcases bevestigen dit (zie 3.2). Het tweede commerciële programma (Geomatic Spark) heeft een score van 80% maar kon een score behaald hebben van 100% door het negeren van DXF 2013. Bovendien kan dit programma, na MeshLab, het grootste aantal formaten inlezen. Qua werking en resultaten kan men MeshLab en Geomatic Spark met elkaar vergelijken. Ze bevatten veel mogelijkheden en bovendien zijn de ingeladen bestanden nog voor bewerking vatbaar. MeshLab en Leica Cyclone zijn de enige programma’s met een topscore waar bewerking van de bestanden nog mogelijk is. De overige goed scorende programma’s zijn pure viewers.

Naargelang de mogelijkheden die de gebruiker heeft kan men opteren om te werken met freeware of commerciële programma’s of een combinatie van beiden. Daar free trials vaak maar voor een bepaalde periode beschikbaar zijn is het gebruik ervan niet altijd aan te raden. Om een optimale werking van de applicatie in dit onderzoek te verzekeren moet men het programma MeshLab downloaden. Dit programma is nodig om de tussenstap uit te voeren wanneer dit noodzakelijk blijkt (3.2). Het is perfect mogelijk om de applicatie te testen met enkel freeware. Naast MeshLab moet men ook beschikken over een programma voor de visualisatie van DXF en CityGML. Diverse keuzes zijn mogelijk maar in navolging van de resultaten uit tabel 68 zou men best opteren voor de FZK Viewer of GML viewer voor de visualisatie van CityGML en Free DWG viewer voor de DXF-resultaten. Bovendien is deze laatste viewer een goede keuze aangezien zowel DXF 2013 als DXF R12/LT2 in alle testcases perfect weergegeven worden. Als men hier moet antwoorden op de vraag welk programma

44

Autodesk 3ds Max, Autodesk Maya, Autodesk Civil 3D, Autodesk Design Review en DWG TrueView.

96

het beste uit dit onderzoek komt dan zal men zich niet enkel kunnen baseren op de gegevens uit tabel 67. Men moet namelijk ook rekening houden met de mogelijkheden dat het programma biedt en het aantal formaten dat het ondersteunt. Rekening houdend met dit alles scoort MeshLab het beste. Het programma ondersteunt een groot aantal formaten, levert goede resultaten in alle cases en biedt naast het weergeven ook de mogelijkheid tot bewerking van het object.

In tabel 68 geeft men een overzicht van het aantal failures per programma, maar men kan de zaak ook anders bekijken door het analyseren van het aantal failures per formaat. In de onderstaande tabel volgt een overzicht.

Tabel 68: Overzicht percentage failures per formaat bij openen in software Bron: eigen verwerking Type targetbestand

Aantal failures (%)

DXF (2013)

84

X3DV

75

STL

40

DXF (R12/LT2)

30

PLY

20

OBJ

0

VRML

0

X3D

0

CityGML

0

OFF

0

XYZ

0

Tabel 68 geeft aan in hoeveel procent van de gevallen men het targetbestand van een bepaald type niet kan openen in een softwareprogramma. Dit wil niet zeggen dat de conversie mislukt is, want ieder targetbestand wordt door minstens 1 softwareprogramma geopend. Zoals eerder al aangetoond geeft DXF 2013 ook hier de minste goede resultaten wegens geen ondersteuning van versie 2013 in vele programma’s. DXF R12/LT2 scoort een stuk beter. In dit onderzoek zijn geen problemen ondervonden met OBJ, VRML, X3D, CityGML, OFF, XYZ. Aangezien OBJ, OFF en XYZ een vrij eenvoudige opbouw hebben waren ook weinig

97

problemen te verwachten. Men zou wel aannemen dat in navolging van X3D ook X3DV goed zou scoren maar dit is echter niet het geval. Omwille hiervan is het zeker aan te raden om met X3D te werken aangezien beiden toch dezelfde inhoud kunnen bevatten. Een vaak voorkomende fout bij STL is te wijten aan de waardes van de normale in het STL-bestand. Zoals besproken in Ho-chan et al.(2002) en Iancu et al. (2010) geeft men best de waarde 0 mee aan deze coördinaten. Bij het converteren heeft men dan ook geopteerd om dit zo te doen. De fout moet men dus elders zoeken. Meer dan waarschijnlijk ligt de oorzaak van het probleem bij het opdelen van de vlakken in driehoeken. Als men de tabellen met de resultaten bekijkt in 3.2 zal men opmerken dat steeds dezelfde programma’s het STL-bestand niet kunnen laden. Het staat buiten kijf dat DXF de meeste moeilijkheden teweegbrengt. Indien men slechts een eenvoudig object (geometrie) dient te beschrijven zonder meer dan zijn het OBJ- of het OFF-formaat de beste opties. Indien men meer mogelijkheden wenst dan maakt men best een keuze uit CityGML, VRML of X3D. Hoe meer mogelijkheden een bestandsformaat biedt, hoe groter de bestandsgrootte. Er is echter geen verband tussen die mogelijkheden en het aantal failures voor dat formaat.

98

4. DISCUSSIE

Dit hoofdstuk biedt in eerste instantie de mogelijkheid om een terugkoppeling te maken naar eerder gevoerd literatuuronderzoek. In tweede instantie wordt er een kritische beoordeling gegeven over het uitgevoerde onderzoek.

Eerst start men met de terugkoppeling naar de literatuurstudie. In deze studie vergaarde men kennis wat betreft de huidige stand van zaken betreffende 3D-opslagformaten en de verzameling van gegevens. Bovendien wou men meer inzicht krijgen in de verschillende visies van diverse auteurs en de resultaten van hun onderzoeken. De studie spitste zich voornamelijk toe op de dataverzamelingsmethoden. In de rapportering is echter geen aandacht besteed aan de visualisatie van formaten met verschillende softwareprogramma’s (dataverwerking). Na evaluatie en bespreking van de literatuurstudie met de promotor is besloten om in het onderzoek zelf geen data te verwerven via de vermelde methodes uit de literatuurstudie. Het leek een beter idee om een aantal formaten van naderbij te bekijken en te bespreken. Daarbij werd geopteerd om een applicatie te schrijven waardoor het mogelijk is de onderzochte formaten te converteren naar elk ander onderzocht formaat. De resultaten van deze conversies zijn daarna geëvalueerd met behulp van verschillende softwarepakketten. De Java-applicatie vormt het hoofdbestandsdeel van dit onderzoek. Omdat hiernaar geen onderzoek werd verricht in de literatuurstudie is een terugkoppeling naar gelijkende studies niet mogelijk.

Hieronder volgt een kritische blik op het onderzoek. Zowel de zwaktes als sterktes worden aangehaald. De ontwikkelde Java-applicatie werkt bijzonder goed voor conversies vanuit DXF, OFF, CityGML, OBJ, STL, PLY en XYZ naar alle andere onderzochte formaten. Bij de conversie vanuit VRML, X3D en X3DV kunnen soms problemen opduiken. Dit houdt in dat de applicatie het sourcebestand niet zal inlezen wanneer de inhoud omvangrijker is dan de geïmplementeerde basis in de applicatie. Desondanks kunnen deze conversies toch plaatshebben door middel van een tussenstap via MeshLab (zie hoofdstuk 3). Een volgende opmerking die men kan maken is dat het algemeen datamodel bestaat uit punten en vlakken. Het genereren van lijnen is niet verwerkt in de applicatie. Dit vormt geen nadeel voor de applicatie aangezien ze uitstekend werkt voor 3D-objecten maar het zou wel een pluspunt zijn indien de applicatie hiermee uitgebreid wordt. Als men het vooropgestelde doel voor ogen houdt dan is het opzet van de applicatie zeker geslaagd. Het was de bedoeling om een 99

standaard basisapplicatie te creëren om 3D-objecten vanuit verschillende formaten te converteren. De applicatie werkt het best met bestanden waar slechts 1 object in beschreven is maar kan ook gebruikt worden voor meer gecompliceerde bestanden. Het converteren zal dan wel meer tijd in beslag nemen. In de basisapplicatie is enkel rekening gehouden met het geometrische aspect. Andere informatie zoals kleur en textuur zijn niet opgenomen. Hiervoor voorziet men wel enkele alternatieven (hoofdstuk 3). Ofwel kan men de applicatie verder uitbreiden zodat kleurinformatie mee opgenomen en omgezet wordt of men kan de kleur na conversie opnieuw manueel toevoegen. Men is hier van mening dat de laatste optie de gemakkelijkste en voordeligste is, aangezien in dit onderzoek duidelijk beschreven is waar men (kleur)informatie dient op te nemen. Het implementeren van deze info in de basisapplicatie zou tijdrovend zijn en niet zo eenvoudig. Natuurlijk is het afhankelijk van de toepassing en het beoogde doel. Indien men vaak met kleuren en andere informatie wenst te werken dan zal de tijd die nodig is voor de implementatie niet opwegen tegen de voordelen op langere termijn. Zoals reeds vermeld gaat het hier om een basisapplicatie die 3D-objecten kan omzetten.

Naargelang de toepassing kan de gebruiker kiezen met welk bestandsformaat hij wenst te werken. Er is getracht om een zo breed mogelijke waaier aan formaten op te nemen in dit onderzoek, doch is dit slechts een selectie uit het ruime aanbod. Dezelfde opmerking kan men ook maken bij de onderzochte software. Er is getracht een passende selectie te maken van de meest voorkomende en populaire formaten en softwarepakketten. Het zou een goed idee geweest zijn om alvorens de selectie te maken een onderzoek te doen aan de hand van enquêtes. Deze peiling zou een concreter overzicht gegeven hebben over de meest gebruikte formaten/softwareprogramma’s. Na analyse van de resultaten gaat de voorkeur hier uit naar de ‘eenvoudige’ formaten. Met ‘eenvoudig’ bedoelt men formaten die enkel geometrie beschrijven aan de hand van punten (puntenlijst) en vlakken (vlakkenlijst). Toch moet men de bedenking maken dat ‘het eenvoudig en gemakkelijk zijn in gebruik’ niet altijd voldoende is om complexere problemen op te lossen. De verwachtingen liggen steeds hoger, zeker wat betreft de presentatie en het uitzicht van 3D-objecten. Zoals gezegd gaan de extra eigenschappen wel verloren tijdens het converteren. Echter kan men bij de eenvoudige formaten deze info na conversie manueel opnieuw toevoegen. Bij gecompliceerdere formaten is meer kennis van zaken nodig maar het is niet onoverkomelijk. Zij die van de toepassing wensen gebruik te maken zijn vaak 100

geïnteresseerden met kennis van zaken. Desondanks is hier getracht om de bespreking en de uitleg zo universeel mogelijk te schrijven. Een selectie vooropstellen van de beste programma’s is min of meer een subjectieve keuze van de gebruiker. De ene zal liever werken met programma A terwijl een ander de voorkeur geeft aan programma B. De voorkeur van de auteur gaat uit naar MeshLab, Solid Works Edrawings, Free DWG Viewer en GML Viewer om alle onderzochte formaten te visualiseren. Deze keuze is deels gebaseerd op de resultaten uit tabel 68 (hoofdstuk 3) maar bevat ook persoonlijke redenen. De programma’s zijn gebruiksvriendelijk, leveren weinig tot geen problemen en het downloaden is eenvoudig. Men hoeft geen expert te zijn om met deze programma’s te werken maar enige basiskennis is wel aangeraden.

De Java-applicatie werkt naar behoren en alle formaten kunnen, al dan niet met een tussenstap, geconverteerd worden. Deze applicatie kan als uitgangspunt dienen voor verder onderzoek. Men heeft getracht een standaardapplicatie op te stellen die men zelf verder kan uitbreiden en aanpassen naar eigen noden. Zo kan men een persoonlijke tool creëren waardoor efficiënt werken mogelijk wordt.

101

5. BESLUIT

In deze masterproef is het de bedoeling een concreet overzicht te geven van volgende formaten: DXF, CityGML, X3D/X3DV, VRML, OBJ, STL, OFF, PLY en XYZ. De zelf ontwikkelde Java-applicatie zorgt er voor dat het mogelijk is om deze formaten te converteren. Om de resultaten hiervan te testen maakt men gebruik van een reeks softwareprogramma’s. Men dient op te merken dat de lijst met software die hier gebruikt is slechts een selectie uit het aanbod is. Men heeft getracht een zo divers mogelijke selectie te maken waarin zowel free trials, commerciële software als freeware te vinden zijn. Uit de resultaten kan men niet aannemen dat een commercieel programma beter zou functioneren dan een freeware pakket. De best functionerende programma’s (dit wil zeggen waar geen failures optreden) zijn Cortona 3D Viewer , FZK Viewer, Free DWG Viewer, MeshLab en Leica Cyclone. Het valt hierbij op dat dit allemaal freeware programma’s zijn met uitzondering van Leica Cyclone. Geomatic Spark (commerciële software) scoort ook bijzonder goed met een percentage van 80%. Dit wil zeggen dat slechts in 20 % van de gevallen het programma een bestand niet correct opent. Vaak krijgt men dan een foutmelding of crasht het programma helemaal zonder enige melding. Het is opmerkelijk dat alle vijf de Autodesk programma’s uit de lijst bijzonder slecht scoren, met op de laatste plaats Autodesk Design Review en DWG TrueView. Deze programma’s werken slechts in 20% van alle gevallen. Deze bevinding doet eveneens afbreuk aan de veronderstelling dat commerciële programma’s beter zouden functioneren. Dit resultaat kan men echter best met een korreltje zout nemen aangezien het resultaat ook door andere factoren kan beïnvloed worden. Daarom is het belangrijk om de formaten die als input gebruikt zijn voor de evaluatie nader te analyseren. Het is mogelijk dat een welbepaald formaat (dat met deze programma’s kan geopend worden) telkens een fout genereert. Deze fout zorgt ervoor dat het desbetreffende programma een lager werkingspercentage zal hebben. Nu is het zo dat de Autodesk programma’s die hier slecht scoren hoofdzakelijk DXFbestanden openen. Laat nu duidelijk zijn dat DXF een ingewikkeld formaat is. Onderzoek wijst uit dat de beschrijving van DXF enorm uitgebreid is en dat de definiëring van een eenvoudig object al snel meerdere pagina’s beslaat. Het is dus niet verwonderlijk dat in deze formaten sneller een foutje sluipt dan in andere formaten. Het grootste probleem echter vormen de verschillende versies. In de loop der jaren is het bestandsformaat gewijzigd en steeds meer uitgebreid om alle entiteiten te kunnen beschrijven. Als men de individuele 102

resultaten uit de cases analyseert, dan zal het opvallen dat DXF 2013 fouten genereert bij de Autodesk programma’s. Men mag echter niet zomaar concluderen dat de Autodesk programma’s slecht scoren aangezien het DXF-formaat ook bij andere programma’s voor problemen zorgt. Dit werpt een ander licht op de zaak. Tussen de best scorende programma’s vindt men met uitzondering van Free DWG Viewer geen enkel programma dat het DXFformaat ondersteunt. Dit is een mogelijke verklaring voor de slechte score van programma’s die DXF ondersteunen.

Als men de failures per formaat bekijkt ziet men dat DXF 2013 het slechtste scoort. In 84% van de gevallen opent het targetbestand niet. Het is niet zo dat de conversie totaal verkeerd gelopen is want elk DXF 2013-targetbestand wordt in minimum 1 viewer gevisualiseerd. Dit geldt trouwens voor alle targetbestanden in dit onderzoek. De achterliggende oorzaak is niet helemaal duidelijk maar telkens de fout optreedt, verschijnt de melding “invalid file version”. Dit wil zeggen dat het desbetreffende programma de versie niet ondersteunt. Het is wel duidelijk dat DXF R12/LT2 het veel beter doet en slechts in 30% van de gevallen niet wil openen. De targetbestanden van het type OBJ, VRML, X3D, CityGML, OFF en XYZ leveren geen problemen op. In navolging van X3D zou men verwachten dat X3DV ook geen failures heeft maar dit is niet wat de resultaten bevestigen. Na DXF 2013 levert X3DV de meeste problemen. Mogelijks komt dit voort uit het gebruik van XML-schema’s in dit formaat. Daarnaast is ook STL bovenaan de lijst terug te vinden. De reden hiervan is waarschijnlijk de opdeling van de vlakken in afzonderlijke driehoeken.

Tot slot kan men de formaten opdelen naargelang hun mogelijkheden. DXF, CityGML, X3D/X3DV en VRML zijn de meest uitgebreide formaten. Men kan besluiten dat er wel degelijk een verband bestaat tussen de mogelijkheden en de bestandsgrootte. Hoe groter de perspectieven van het formaat hoe aanzienlijker de bestandsgrootte. Tussen de mogelijkheden van een formaat en de failures eigen aan dit formaat is geen duidelijk verband te merken. Van deze groep formaten scoren enkel DXF (2013 en R12/LT2) en X3DV slecht. De formaten XYZ, OFF, OBJ en PLY die enkel geometrie en kleurdefinities opnemen scoren gemiddeld beter. Enkel PLY heeft een failure percentage van 20%. Als laatste is er ook nog STL. Dit formaat beschrijft enkel geometrie aan de hand van punten en driehoekige vlakken en geeft in 40% van de gevallen een failure. Dit is meer dan waarschijnlijk te wijten aan de omzetting van vlakken in driehoeken.

103

6. REFERENTIELIJST

6.1 Literatuur

Ames, A. L., Nadeau, D. R., Moreland, J. L. (1997) The VRML 2.0 Sourcebook. New York: Wiley Computer Publishing. Amiano, M., D’Cruz, C., Ethier, K., Thomas, M. D. (2006) XML: Problem - Design – Solution. Indianapolis: Wiley Publishing. Ammeraal, L. (2000) Basiscursus Java (2e herziene druk). Schoonhoven: Academic Service.

Angeles, J., Kövecses, J., Boulet, B., Siddiqi, K., Clark, J. (Eds.) (2010) Brain, Body and Machine. Berlin: Springer. Baerten, H., Van Reeth, F. (1998) “Using VRML and JAVA to visualize 3D algorithms in computer graphics education”. Computer Networks and ISDN Systems. 30(20-21), 1833-1839. Barnes, D.J., Kölling, M. (2009) Programmeren in Java met BlueJ – een ‘objecten eerst’ -benadering (4e Editie). Amsterdam: Pearson Education Benelux.

Bateman, R., Olsson, R. (2010) The Essential Guide to 3D in Flash. New York: Apress.

Brutzman, D., Daly, L. (2007) X3D: Extensible 3D Graphics for Web Authors. Burlington: Morgan Kaufmann Publishers. Burggraf, D.S. (2006) “Geography Markup Language”. Data Science Journal. 5, 178-204. Cao, Z., Hu, Z. (2012) “Design virtual reality scene roam for tour animations base on VRML and Java”. Physics Procedia. 25, 693-699. Çöltekin, A., Heikkinen J., Rönnholm P. (1999) “Studying Geometry Color and Texture in VRML”. Surveying Science in Finland.17 (1-2), 65-90.

104

Dasso, A., Funes, A. (Eds.) (2007) Verification, Validation and Testing in Software Engineering. Hershey: Idea Group Publishing. Deitel, P., Deitel, H. (2010) JAVA How to Program (8th Edition). New Jersey: Pearson Education. Furht, B. (Ed.) (2008) Encyclopedia of Multimedia 2nd Edition. New York: Springer Science and Business Media LLC.

Geroimenko, V., Chen, C. (2005) Visualizing Information Using SVG and X3D: XML Based Technologies for the XML-base Web. Berlin: Springer. Goldberg, K. -H. (2009) XML: Visual Quickstart Guide (2nd Edition). San Francisco: Peachpit Press.

Hartman, J., Wernecke, J. (1996) The VRML 2.0 Handbook: Building Moving Worlds on the Web. Londen: Pearson PLC. Ho-chan, K., Hong-tae, C., Hyoung-kook, L., Seok-hee, L. (2002) “A study on rapid prototyping using VRML model”. International Journal of the Korean Society of Precision Engineering. 3 (2), 5-14. Iancu, C., Iancu, D., Stăncioiu, A. (2010) “From CAD model to 3D print via STL file format”. Revista Fiabilitate si Durabilitate. 1, 73-80.

Kloss, J. H. (2010) X3D Programmierung Interaktiver 3D-Anwendungen fur das Internet. München: Pearson Education Deutschland. Kolbe, T. H., Gröger, G., Plümer L. (2005) “CityGML – Interoperable access to 3D city models”. Delft: Proceedings of the Int. Symposium on Geo-information for Disaster Management on 21-31 March 2005. Laan, G. (2007) En dan is er …Java. Den Haag: Sdu Uitgevers.

105

Lanier, L. (2008) Advanced Maya Texturing and Lighting. Indianapolis: Wiley Publishing. Li, S., Isele, J., Bretthauer, G. (2008) “Proposed methodology for generation of building information model with laserscanning”.Tsinghua Science & Technology. 13 (1), 138-144.

Lombard, M. (2008) SolidWorks Surfacing and Complex Shape Modeling Bible. Indianapolis: Wiley Publishing. Mao, B., Ban, Y., Harrie, L. (2009) “A framework for generalization of 3D city models based on Citygml and X3D”. ISPRS Commission IV. 3, 9 pag.

McConnell, J.J. (2006) Computer Graphics: Theory into Practice. Sudbury: Jones and Bartlett Publishers. McHenry, K., Bajcsy, P. (2008) “An overview of 3D data content, file formats and viewers”. Technical Report, National Center for Supercomputing Applications, University of Illinois at Urbana-Champaign, ISDA 08-02, 21 pag. Mollet, B. (2004) “Praktische studie en analyse van VRML, X3D en MPEG-4 systems”. Onuitgegeven scriptie, Universiteit Gent: Faculteit Toegepaste Wetenschappen.

Mukundan, R. (2012) Advanced Methods in Computer Graphics. Berlin Heidelberg: Springer.

Murdocca, M.J., Heuring, V.P. (2000) Principles of Computer Architecture. New Jersey: Prentice Hall. Murray, J. D., vanRyper, W. (1996) Encyclopedia of Graphics File Formats (2nd Edition). Sebastopol: O’Reilly Media Inc.

Patnaik, S., Yang, Y.-M. (Eds.) (2012) Soft Computing Techniques in Vision Science. Berlin Heidelberg: Springer. Qi, S. (2012) “Virtual interior design based on VRML and JAVA”. Physics Procedia. 33, 1614-1620. 106

Rahman, A. -A., Zlatanova, S., Coors, V. (Eds.) (2006) Innovations in 3D Geo Information Systems. Berlin Heidelberg: Springer.

Rideout, P. (2010) iPhone 3D Programming: Developing Graphical Applications with OpenGL ES. Sebastopol: O’Reilly Media Inc. Rock, S.J., Wozny, M.J. (1991) “A flexible file format for solid freeform fabrication”. Solid Freeform Fabrication Symposium Proceedings – University of Texas, 12 pag.

Shekhar, S., Xiong, H. (Eds.) (2008) Encyclopedia of GIS. New York: Springer Science and Business Media LLC. Szilvśi-Nagy, M., Mátyási, G. (2003) “Analysis of STL-files”. Mathematical and Computer Modelling. 38(7), 945-960. Wu, T., Cheung, E.H.M. (2006) “Enhanced STL”. Advanced Manufacturing Technology. 29 (11-12), 1143-1150. Zhang, S., Gan, J., Xu, J., Lv, G. (2008) “Study on a native XML database based GML storage model”. The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences - XXIst ISPRS Congress – Technical Commision IV July 3-11, 45-52.

6.2 Internetbronnen 3D Systems (2012) 3D content – to – Print Solutions. http://www.3dsystems.com/. 20/02/2013.

3D Systems (2012) Selective Laser Sintering (SLS). http://production3dprinters.com/sls/selective-laser-sintering. 20/02/2013.

107

Albert, J., Bachmann, M., Hellmeier, A. (2003) Zielgruppen und Anwendungen für Digitale Stadtmodelle und Digitale Geländemodelle - Erhebungen im Rahmen der SIG 3D der GDI NRW. http://www.ikg.uni-bonn.de/fileadmin/sig3d/pdf/Tabelle_Anwendungen_Zielgruppen.pdf. 07/07/2013.

Autodesk (s.d.) Ambient Color. http://docs.autodesk.com/3DSMAX/15/ENU/3ds-Max-Help/index.html?url=files/GUIDFE816049-4624-46CD-BAFC-F59931A92F06.htm,topicNumber=d30e599443. 16/04/2013.

Autodesk (s.d.) Diffuse Color. http://docs.autodesk.com/3DSMAX/15/ENU/3ds-Max-Help/index.html?url=files/GUID69603DC2-F58C-4053-A955-EA19FDB8D084.htm,topicNumber=d30e392128. 16/04/2013.

Autodesk (s.d.) Specular Color. http://docs.autodesk.com/MAXDES/13/ENU/Autodesk%203ds%20Max%20Design%202011 %20Help/index.html?url=./files/WSf742dab0410631334fd1fb1c112a1ce99ff7f96.htm,topicNumber=d0e329083. 16/04/2013.

Autodesk Inc. (2013) Autodesk® AutoCAD® 2014. http://images.autodesk.com/adsk/files/autocad_2014_pdf_dxf_reference_enu.pdf. 16/04/2013.

Bray, T., Paoli, J., Spergberg-McQueen, C.M., Maler, E., Yergeau, F. (Eds.) (2008) Extensible Markup Language (XML) 1.0 (Fifth Edition) - W3C Recommendation 26 November 2008. http://www.w3.org/TR/REC-xml/#sec-intro. 10/07/2013.

Brink, E., Steenberg, E. (2007) The Verse Specification: A platform for Sharing 3D Data. http://verse.blender.org/fileadmin/verse/spec/protocol-datatypes.html#type-real32. 28/02/2013.

Computer Graphics Group (s.d.) Sample .obj Files. http://groups.csail.mit.edu/graphics/classes/6.837/F03/models/. 02/08/2013.

108

Getreuer, P. (2004) The PLY-format. http://www.mathworks.com/matlabcentral/fx_files/5459/1/content/ply.htm. 06/02/2013.

Gröger, G., Kolbe, T.H., Nagel, C., Häfele, K.-H. (Eds.) (2012) OGC City Geography Markup Language (CityGML) Encoding Standard. http://www.opengeospatial.org/standards/citygml. 07/07/2013.

Heynick, M., Stotz, I. (2006) 3D CAD, CAM and Rapid Prototyping. http://enacoc.epfl.ch/files/content/sites/enacco/files/3D%20CAD%20CAM%20and%20Rapid %20PrototypingV1.1.pdf. 20/02/2013.

Institute for Geodesy and Geoinformation Science, Technische Universität Berlin (2012) citygml4j. http://opportunity.bv.tu-berlin.de/software/projects/citygml4j/files. 07/05/2013.

Nadeau, D.R. (s.d.) Building a VRML world. http://www.vislab.uq.edu.au/users/manuals/vrml97/slides/mt0019.htm. 03/04/2013.

Nadeau, D.R. (s.d.) Lighting your World, Example. http://www.vislab.uq.edu.au/users/manuals/vrml97/examples/temple.wrl. 03/04/2013.

N.N. (s.d.) Kleuren in 3D. http://lesmodules.lamp.tudelft.nl/hoofdstuk-2/meer-3d-objecten/. 16/04/2013.

N.N. (s.d.) Objecten in 3D. http://lesmodules.lamp.tudelft.nl/hoofdstuk-2/zelf-uitproberen/. 16/04/2013.

N.N. (s.d.) RapidPrototyping.NL. http://www.rapidprototyping.nl/content.php. 20/02/2013.

N.N. (s.d.) VRML is ready for prime time. http://www.buddycom.com/vrml/tgsmods/index.html. 02/08/2013.

109

N.N. (2009) Vertex Normals. http://www.visualization.hpc.mil/wiki/Vertex_Normals. 02/03/2013.

N.N. (2011) Verdieping stereolithografie. http://www.skmrapid.nl/default.asp/id,51/index.html. 20/02/2013.

Open Geospatial Consortium (s.d.) Geography Markup Language. http://www.opengeospatial.org/standards/gml. 07/07/2013.

Portele, C. (2007) OpenGIS® Geography Markup Language (GML) Encoding Standard. http://www.opengeospatial.org/standards/gml.10/07/2013.

Princeton University (2003) Object File Format (.off). http://shape.cs.princeton.edu/benchmark/documentation/off_format.html. 12/07/2013.

Turk, G. (1994) PLY Files an ASCII Polygon File Format. http://people.sc.fsu.edu/~jburkardt/data/ply. 02/08/2013.

Turk, G. (1994) The PLY Polygon File Format. http://www.cs.virginia.edu/~gfx/Courses/2001/Advanced.spring.01/plylib/Ply.txt. 07/02/2013.

VDX. (2007) Simple STL-Files for Testing Dimensions. http://forums.reprap.org/read.php?88,6830,220658. 02/08/2013. Web 3D Consortium (s.d.) Extensible 3D (X3D) Encodings – Part 2: Classic VRML Encoding. http://www.web3d.org/files/specifications/19776-2/V3.2/Part02/examples.html. 02/08/2013.

Web 3D Consortium (s.d.) X3D Example Archives: Basic, Student Projects, Laetitia. http://www.web3d.org/x3d/content/examples/StudentProjects/_pages/page23.html. 02/08/2013.

W3C (s.d.) The Virtual Reality Modeling Language. http://www.web3d.org/x3d/specifications/vrml/ISO-IEC-14772-VRML97/. 05/04/2013. 110

WC3 (s.d.) What is X3D?. http://www.web3d.org/realtime-3d/x3d/what-x3d/. 06/04/2013. W3C (s.d.) X3D International Specification Standard –X3D Overview. http://www.web3d.org/x3d/specifications/x3d/. 06/04/2013.

6.3 Software

Autodesk 3ds Max 2013 Autodesk Civil 3D 2013 Autodesk Design Review 2011 Autodesk Maya 2013 BS Contact 8.01 CCViewer 1.19 CloudCompare 2.4 Cortona 3D Viewer 7.0 DWG TrueView 2011 Flux Studio 2.1 Free DWG Viewer 7.1.1.11 Free WRL Launcher 1.22.12 FZK Viewer 2.3 Geomatic Spark GML Viewer 4.0 Leica Cyclone MeshLab 1.3.2 NetBeans IDE 7.3 SketchUp 2013 SolidWorks E-Drawings 2013 Trimble Realworks Viewer 7.1 Visual Paradigm for UML 10.2

111

7. BIJLAGEN

7.1 Java class bibliotheek citygml4j

Tabel 69: Java class bibliotheek citygml4j Bron: http://opportunity.bv.tu-berlin.de/software/projects/citygml4j/files, 07/05/2013 package thisProject; /* * This file is part of citygml4j. * Copyright (c) 2007 - 2010 * Institute for Geodesy and Geoinformation Science * Technische Universitaet Berlin, Germany * http://www.igg.tu-berlin.de/ * * The citygml4j library is free software: * you can redistribute it and/or modify it under the terms of the * GNU Lesser General Public License as published by the Free * Software Foundation, either version 3 of the License, or * (at your option) any later version. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with this library. If not, see * . */ import java.io.BufferedReader; import java.io.File; import java.io.FileReader; import java.text.SimpleDateFormat; import java.util.ArrayList; import java.util.Date; import java.util.List; import java.util.StringTokenizer; import org.citygml4j.CityGMLContext; import org.citygml4j.builder.CityGMLBuilder; import org.citygml4j.factory.GMLGeometryFactory; import org.citygml4j.model.citygml.CityGMLClass; import org.citygml4j.model.citygml.building.AbstractBoundarySurface; import org.citygml4j.model.citygml.building.BoundarySurfaceProperty; import org.citygml4j.model.citygml.building.Building; import org.citygml4j.model.citygml.building.GroundSurface; import org.citygml4j.model.citygml.building.RoofSurface; import org.citygml4j.model.citygml.building.WallSurface; import org.citygml4j.model.citygml.core.CityModel; import org.citygml4j.model.citygml.core.CityObjectMember; import org.citygml4j.model.gml.geometry.aggregates.MultiSurface; import org.citygml4j.model.gml.geometry.aggregates.MultiSurfaceProperty; import org.citygml4j.model.gml.geometry.complexes.CompositeSurface; import org.citygml4j.model.gml.geometry.primitives.Polygon; import org.citygml4j.model.gml.geometry.primitives.Solid; import org.citygml4j.model.gml.geometry.primitives.SolidProperty; import org.citygml4j.model.gml.geometry.primitives.SurfaceProperty; import org.citygml4j.model.module.citygml.CityGMLVersion; import org.citygml4j.util.gmlid.DefaultGMLIdManager; import org.citygml4j.util.gmlid.GMLIdManager; import org.citygml4j.xml.io.CityGMLOutputFactory; import org.citygml4j.xml.io.writer.CityGMLWriter; import java.util.Scanner; import static thisProject.Data.pointList;

112

public class BuildingCreator implements Data{ public static void main(String[] args) throws Exception { new BuildingCreator().doMain(); } public void doMain() throws Exception { SimpleDateFormat df = new SimpleDateFormat("[HH:mm:ss] "); System.out.println(df.format(new Date()) + "setting up citygml4j context and JAXB builder"); CityGMLContext ctx = new CityGMLContext(); CityGMLBuilder builder = ctx.createCityGMLBuilder(); System.out.println(df.format(new Date()) + "creating LOD2 building as citygml4j in-memory object tree"); GMLGeometryFactory geom = new GMLGeometryFactory(); GMLIdManager gmlIdManager = DefaultGMLIdManager.getInstance(); Building building = new Building(); Polygon ground = geom.createLinearPolygon(new double[] {0,0,0, 0,12,0, 6,12,0, 6,0,0, 0,0,0},3); Polygon wall_1 = geom.createLinearPolygon(new double[] {6,0,0, 6,12,0, 6,12,6, 6,0,6, 6,0,0}, 3); Polygon wall_2 = geom.createLinearPolygon(new double[] {0,0,0, 0,0,6, 0,12,6, 0,12,0, 0,0,0}, 3); Polygon wall_3 = geom.createLinearPolygon(new double[] {0,0,0, 6,0,0, 6,0,6, 3,0,9, 0,0,6, 0,0,0}, 3); Polygon wall_4 = geom.createLinearPolygon(new double[] {6,12,0, 0,12,0, 0,12,6, 3,12,9, 6,12,6, 6,12,0}, 3); Polygon roof_1 = geom.createLinearPolygon(new double[] {6,0,6, 6,12,6, 3,12,9, 3,0,9, 6,0,6}, 3); Polygon roof_2 = geom.createLinearPolygon(new double[] {0,0,6, 3,0,9, 3,12,9, 0,12,6, 0,0,6}, 3); ground.setId(gmlIdManager.generateUUID()); wall_1.setId(gmlIdManager.generateUUID()); wall_2.setId(gmlIdManager.generateUUID()); wall_3.setId(gmlIdManager.generateUUID()); wall_4.setId(gmlIdManager.generateUUID()); roof_1.setId(gmlIdManager.generateUUID()); roof_2.setId(gmlIdManager.generateUUID()); // lod2 solid List<SurfaceProperty> surfaceMember = new ArrayList<SurfaceProperty>(); surfaceMember.add(new SurfaceProperty('#' + ground.getId())); surfaceMember.add(new SurfaceProperty('#' + wall_1.getId())); surfaceMember.add(new SurfaceProperty('#' + wall_2.getId())); surfaceMember.add(new SurfaceProperty('#' + wall_3.getId())); surfaceMember.add(new SurfaceProperty('#' + wall_4.getId())); surfaceMember.add(new SurfaceProperty('#' + roof_1.getId())); surfaceMember.add(new SurfaceProperty('#' + roof_2.getId())); CompositeSurface compositeSurface = new CompositeSurface(); compositeSurface.setSurfaceMember(surfaceMember); Solid solid = new Solid(); solid.setExterior(new SurfaceProperty(compositeSurface)); building.setLod2Solid(new SolidProperty(solid)); // thematic boundary surfaces List boundedBy = new ArrayList(); boundedBy.add(createBoundarySurface(CityGMLClass.BUILDING_GROUND_SURFACE, ground)); boundedBy.add(createBoundarySurface(CityGMLClass.BUILDING_WALL_SURFACE, wall_1)); boundedBy.add(createBoundarySurface(CityGMLClass.BUILDING_WALL_SURFACE, wall_2)); boundedBy.add(createBoundarySurface(CityGMLClass.BUILDING_WALL_SURFACE, wall_3)); boundedBy.add(createBoundarySurface(CityGMLClass.BUILDING_WALL_SURFACE, wall_4)); boundedBy.add(createBoundarySurface(CityGMLClass.BUILDING_ROOF_SURFACE, roof_1)); boundedBy.add(createBoundarySurface(CityGMLClass.BUILDING_ROOF_SURFACE, roof_2)); building.setBoundedBySurface(boundedBy); CityModel cityModel = new CityModel(); cityModel.setBoundedBy(building.calcBoundedBy(false)); cityModel.addCityObjectMember(new CityObjectMember(building)); System.out.println(df.format(new Date()) + "writing citygml4j object tree"); CityGMLOutputFactory out = builder.createCityGMLOutputFactory(CityGMLVersion.DEFAULT); CityGMLWriter writer = out.createCityGMLWriter(new File("LOD2_Building_v200.gml")); writer.setPrefixes(CityGMLVersion.DEFAULT); writer.setSchemaLocations(CityGMLVersion.DEFAULT);

113

writer.setIndentString(" "); writer.write(cityModel); writer.close(); System.out.println(df.format(new Date()) + "CityGML file LOD2_Building_v200.gml written"); System.out.println(df.format(new Date()) + "sample citygml4j application successfully finished"); } private BoundarySurfaceProperty createBoundarySurface(CityGMLClass type, Polygon geometry) { AbstractBoundarySurface boundarySurface = null; switch (type) { case BUILDING_WALL_SURFACE: boundarySurface = new WallSurface(); break; case BUILDING_ROOF_SURFACE: boundarySurface = new RoofSurface(); break; case BUILDING_GROUND_SURFACE: boundarySurface = new GroundSurface(); break; } if (boundarySurface != null) { boundarySurface.setLod2MultiSurface(new MultiSurfaceProperty(new MultiSurface(geometry))); return new BoundarySurfaceProperty(boundarySurface); } return null; } }

7.2 Volledige Java-applicatie

De volledige Java-applicatie kan men vinden in de digitale bijlage.

114

Onderzoek naar de verwerking, uitwisseling en visualisatie van 3D-data met diverse opslagformaten

Recommend Documents