3D Visualisierung technischer Daten in Webapplikationen

Größe: px
Ab Seite anzeigen:

Download "3D Visualisierung technischer Daten in Webapplikationen"

Transkript

1 Fachbereich Elektrotechnik und Informatik; Bochum University of Applied Sciences 3D Visualisierung technischer Daten in Webapplikationen Bachelorthesis in Studiengang Mechatronik & Informationstechnologie Dirk Cziesla Version vom 27. März 2014 Betreut von Prof. Dr. rer. Jörg Frochte (Hochschule Bochum) Dipl.-Ing. Jörg Gudat (Gudat Consulting)

2 Copyright und Bildquellen Text: Copyright (c) 2013 Dirk Cziesla Bilder und Skizzen, soweit nicht anders angegeben: Copyright (c) 2013 Dirk Cziesla Lizenz: CC-by-nc-nd (Version 3.0) Den rechtsverbindlichen Lizenzvertrag finden Sie unter dem oben angegebenen Link. Es folgt eine vereinfachte Zusammenfassung des Vertrages in allgemeinverständlicher Sprache ohne juristische Wirkung. Es ist Ihnen gestattet das Skript zu vervielfältigen, zu verbreiten und öffentlich zugänglich zu machen sofern Sie folgende Bedingungen einhalten: Namensnennung: Sie müssen die Urheberschaft ausreichend deutlich benennen, einen Link zur Lizenz beifügen. Diese Angaben dürfen in jeder angemessenen Art und Weise gemacht werden, allerdings nicht so, dass der Eindruck entsteht, der Lizenzgeber unterstütze gerade Sie oder Ihre Nutzung des Werks besonders. Keine kommerzielle Nutzung: Sie dürfen das Material nicht für kommerzielle Zwecke nutzen. Keine Bearbeitung: Wenn Sie das Material remixen, verändern oder darauf anderweitig direkt aufbauen, dürfen Sie die bearbeitete Fassung des Materials nicht verbreiten. Lizenzangabe: Sie müssen Anderen alle Lizenzbedingungen mitteilen, die für dieses Werk gelten. Am einfachsten ist es, wenn Sie dazu einen Link auf den Lizenzvertrag (siehe oben) einbinden. Abweichende Lizenzen für einzelnen Bilder und Skizzen werden ggf. separat angegeben. Es wurde jedoch darauf geachtet, dass keine dieser Lizenzen die Möglichkeiten der Rechte im obigen Sinne einschränkt. Codebeispiele dürfen unter der BSD-3-Clause verwendet und weitergegeben werden.

3 Abstract Diese Bachelor-Arbeit beschäftigt sich mit der 3D Visualisierung technischer Daten in Webapplikationen. Ziel ist es dabei prototypisch darzustellen wie performant eine Visualisierung von 3D-Daten im Browser gelingen könnte. Um dieses Ziel zu erreichen, werden zuerst die verschiedenen Möglichkeiten Software in das Web zu übertragen vorgestellt. Als Technologien für die Umsetzung wird sich für WebSockets und WebGL entschieden. Mit diesen beiden Technologien wird, basierend auf einer bereits existierenden Anwendung, ein Prototyp als Webanwendung entwickelt. Eine besondere Herausforderung stellt dabei das Übertragen der sehr großen Gitter-Daten dar. Speziell für diesen Anwendungsfall wird daher ein Datenformat entwickelt, bei dem die Gitter-Daten möglichst kompakt übertragen werden. Eine weitere Herausforderung ist das Transparent Schalten von einzelnen Punkten in einem 3D-Gitter. Diese Funktion wird nicht nativ unterstützt und muss daher mithilfe von einem eigenen Shader umgesetzt werden. Abschließend wird die Umsetzung der sonstigen GUI-Elemente und möglichen Techniken zur Verbesserung der Datenübertragung vorgestellt.

4 Inhaltsverzeichnis 1 Einleitung 4 2 Grundlagen und Technologien Möglichkeiten zur Visualisierung von Daten im Browser SVG Application-Streaming und Anwendungsserver WebGL Zwischenfazit Visualisierung HTML JSON Datenübertragung zwischen Server und Browser GET- und POST-Anfragen (Long) Polling WebSocket Zwischenfazit Datenübertragung Echtzeit- und Performance-Anforderungen für Webapplikationen Anforderungsanalyse für den Prototypen Anforderungen Bedienungsanforderungen Datenmenge und Performance Sicherheit Abgeleitete Software- und Systemarchitektur Technische Umsetzung WebGL Detailliertere Technologiebetrachung Gemeinsamkeiten und Unterschiede zu OpenGL Interaktion mit JavaSkript D Visualisierung der Simulationsdaten

5 4.2.1 Verwendete Bibliotheken Anbinden des Backends Das Übertragunsformat RAW-Format Perspektivische und Orthographische Ansichten Reines WebGL vs Three.js MeshBasicMaterial, ShaderMaterial und Transparenz Auswahl von Elementen Ausblenden von Elementen Legende Umsetzung der sonstigen GUI-Elemente (Mögliche) Techniken zur Verbesserung der Datenübertragung Coarsening Trennung von Gitter- und Lösungsdaten Fazit und Ausblick 78 Literatur- und Quellenverzeichnis 88 Eidesstattliche Erklärung 89 3

6 1 Einleitung Die Visualisierung von technischen Daten findet sich in vielen Bereichen wieder. Ob in der Biologie, Chemie, Physik oder Medizin, fast immer gibt es Anwendungsfälle, um mit einer Visualisierung die Lösung eines Problems etwas besser darzustellen. Einige Beispiele dafür sind die Visualisierung von Gelände in 3D, Visualisierung von Daten einer Simulation (Tornadosimulator, Erdbebensimulator, Finite Elemente Simulation) oder auch die Visualisierung der Daten aus einem MRT (Magnetresonanztomographie) Scan. Ein Beispiel aus dem Bereich der Finite Elemente Simulation ist das Projekt SimCloud. Dieses kombiniert Aspekte von Cloud Computing, maschinellem Lernen und Simulation. Hauptsächlich wird sich jedoch mit der Finite Elemente Simulation (FES) auf verteilten Systemen beschäftigt, wobei die Probleme mit der Finite-Elemente-Methode (FEM) gelöst werden (für weitere Informationen zur FEM siehe: [FROC2005, S. 25ff]). Die Probleme bewegen sich hauptsächlich im Bereich CAE (Computer Aided Engineering) und CAD (Computer Aided Design). Zu Beginn dieser Bachelor-Arbeit besteht die in dem Projekt entwickelte Software aus zwei Komponenten. Zum einen gibt es das Host-Software-Backend (FEMCore) und zum anderen die grafische Benutzeroberfläche (GUI) zur Ansteuerung bzw. Bedienung des FEMCore, welche als wxwidgetgui bezeichnet wird. Sowohl FEMCore als auch wxwidgetgui sind aktuell nur auf dem Betriebssystem Linux lauffähig. Ziel dieser Bachelor-Arbeit ist es, anhand des oben erwähnten Problemkomplexes prototypisch darzustellen, wie performant eine Visualisierung von 3D-Daten im Browser gelingen könnte. In Kapitel 2 werden die Technologien vorgestellt, welche für die Portierung der Funktionalitäten verwendet werden könnten. Dabei werden zuerst die verschiedenen Möglichkeiten zur Visualisierung von Daten im Browser miteinander verglichen. Bei diesem Vergleich stellt sich heraus, dass WebGL die sinnvollste der vorgestellten Möglichkeiten ist und daher bei 4

7 der 3D-Visualisierung zur Verwendung kommt. Damit ist festgelegt, dass die Applikation als Webapplikation umgesetzt wird. Diese wird als WebGUI bezeichnet. Anschließend werden die zwei Technologien HTML5 und JSON erklärt, die die Grundlage für diese Webapplikation bilden. Darauf basierend werden die Möglichkeiten zur Kommunikation zwischen Server und Browser verglichen. Dabei stellt sich heraus, dass WebSocket aufgrund diverser Vorteile für die Umsetzung Verwendung finden soll. Abschließend werden die Echtzeit- und Performanceanforderungen für Webapplikationen in Kapitel 2.5 ermittelt. Dabei zeigt sich, dass es diverse Nachteile bei der Verwendung einer Web- anstelle einer Desktop-Applikation gibt, vor allem was die Anbindung an den FEMCore angeht. Kapitel 3 behandelt die Anforderungsanalyse für die Webapplikation. Im ersten Abschnitt werden die Anforderungen aus dem Lastenheft für die wxwidgetgui abgeleitet, welche sich in Bedienungsanforderungen, Datenmenge und Performance und Sicherheit unterteilen lassen. In Kapitel wird dabei festgestellt, dass (je nach Größe des Problems) DSL6000 bzw. VDSL 25 als minimale Voraussetzung gilt. Anschließend werden in Kapitel die verschiedenen Möglichkeiten zur Erhöhung der Verbindungssicherheit vorgestellt. Zum Schluss wird für die zuvor spezifizierten Anforderungen die Software- und Systemarchitektur generiert. Dabei wird das FEMInterface definiert, welches die Verbindung zwischen WebGUI und FEMCore darstellt und damit die Herausforderung der Kommunikation zwischen Browser und C++-Backend beseitigt. Die Umsetzung der Software- und Systemarchitektur wird in Kapitel 4 durchgeführt. Hierzu wird zuerst in Kapitel 4.1 die Technologie WebGL weiter vertieft. Dabei werden die Unterschiede zu OpenGL erklärt, welche jedoch keine Auswirkung auf das Projekt haben. Anschließend wird in Kapitel 4.2 die Visualisierung der Simulationsdaten umgesetzt. Da eine eigene Implementierung eines WebSocket-Servers und eines JSON-(De)Serialisierers mit einem zu großen Arbeits- und Zeitaufwand verbunden ist, werden in Kapitel Bibliotheken mit der benötigten Funktionalität ermittelt. Mithilfe dieser Bibliotheken wird der FEMCore mit der WebGUI über das FEMInterface verbunden. Als Übertragungsformat wird dabei JSON verwendet, welches in Kapitel definiert wird. Dies führt jedoch zu einer weiteren Herausforderung, da aufgrund der großen Menge an 5

8 Overhead bei JSON ein weiteres Übertragungsformat für besonders große Dateien (Gitter- Dateien) benötigt wird. Dieses wird in Kapitel definiert und als RAW-Format bezeichnet. Mit der Erklärung der Implementierung des WebGL-Teils wird in Kapitel begonnen. Dafür werden zuerst die perspektivische und die orthographische Ansicht miteinander verglichen, was darin resultiert, dass die perspektivische Ansicht hier Verwendung findet. Anschließend wird ein Vergleich zwischen reinem WebGL und der Bibliothek Three.js aufgestellt. Aufgrund der besseren Wartbarkeit und auch der besseren Unterstützung für mehrere Entwickler wird Three.js bei der 3D-Visualisierung vorgezogen. Basierend auf den Anforderungen an das Auswählen und Ausblenden von Elementen aus Kapitel 3 wird im Kapitel vorgestellt, wie Transparenz für einzelne Punkte in Three.js möglich ist. Dies stellt eine Herausforderung dar, da es nicht ohne weiteres möglich ist, die Transparenz für einzelne Punkte in Three.js zu verändern. Kapitel behandelt daraufhin das Auswählen von Elementen und Kapitel das Ausblenden von Elementen. Abschließend werden in Kapitel die verschiedenen Möglichkeiten zur Umsetzung einer Legende erläutert. In Kapitel 4.3 wird die Umsetzung der sonstigen GUI-Elemente vorgestellt. Das Entwickeln von eigenen GUI-Elementen ist mit viel Arbeits- und Zeitaufwand verbunden, daher wird auch hier eine Bibliothek mit den benötigten Funktionalitäten ermittelt. Im letzten Kapitel 4.4 werden verschiedene mögliche Techniken zur Verbesserung der Datenübertragung vorgestellt. Abgeschlossen wird diese Bachelor-Arbeit mit einem Fazit und Ausblick auf die weitere Arbeit in Kapitel 5. 6

9 2 Grundlagen und Technologien In diesem Kapitel werden die für den Prototypen ausschlaggebenden Technologien und deren Grundlagen erläutert. Dabei wird zuerst auf die verschiedenen Möglichkeiten zur Visualisierung von technischen Daten im Browser eingegangen. Anschließend werden die für die Realisierung des Prototypen als Webapplikation relevanten Technologien HTML5 und JSON vorgestellt, worauf ein Vergleich der Möglichkeiten zur Datenübertragung zwischen Server und Browser folgt. Abschließend werden die Echtzeit- und Performance- Anforderungen für Webapplikationen ermittelt. 2.1 Möglichkeiten zur Visualisierung von Daten im Browser Dieser Abschnitt dient dazu die verschiedenen Technologien näher zu erläutern, die zur Visualisierung von technischen Daten im Webbrowser verwendet werden können. Dabei stellt Application-Streaming eine Ausnahme dar, da diese Technologie nicht ausschließlich im Webbrowser ausgeführt wird SVG SVG ist die erste Technologie, die für die Visualisierung der 3D-Daten im Browser in Frage kommt. SVG steht für Scalable Vector Graphics (engl. für skalierbare Vektorgrafik ). Hierbei handelt es sich nicht um ein Rastergrafikformat wie GIF, JPEG oder PNG, sondern um eine Vektorgrafik. Bei diesen werden nicht die einzelnen Pixel in einer Matrix abgespeichert, sondern die Beschreibung der Schritte, die erforderlich sind, um die gewünschte Grafik zu zeichnen. Das Format ist somit auflösungsunabhängig und daher skalierbar. SVG- Grafiken werden in allen aktuellen Browsern unterstützt. Tabelle 2.1 auf Seite 8 zeigt die verschiedenen Browser jeweils mit der Version, seit der SVG unterstützt wird. Zusätzlich wird die aktuelle Version als Referenzwert angegeben. 7

10 Tabelle 2.1: SVG Unterstützung, Quelle: [DEVE2014a] Browser Version Aktuelle Version Internet Explorer Mozilla Firefox Google Chrome Apple Safari Opera Der Aufbau einer sehr einfachen SVG-Datei ist in Listing 2.1 dargestellt. Listing 2.1: Aufbau einer einfachen SVG Datei [FLAN2012, S. 666f] 1 <! Eine SVG F i g u r beginnen und unserem Namensraum d e k l a r i e r e n > 2 <svg xmlns= h t t p : //www. w3. org /2000/ svg 3 <! Das K o o r d i n a t e n s y s tem f ü r d i e F i g u r. > 4 viewbox= > 5 <! E i n i g e D e f i n i t i o n e n e i n r i c h t e n, d i e w i r nutzen werden. > 6 <d e f s> 7 <! Ein F a r b g r a d i e n t names f a d e. > 8 <l i n e a r G r a d i e n t i d= f a d e > 9 <s t o p o f f s e t= 0% stop c o l o r= #008 /> 10 <s t o p o f f s e t= 100% stop c o l o r= #c c f /> 11 </ l i n e a r G r a d i e n t> 12 </ d e f s> 13 <! Ein Rechteck mit einem d i c k e n schwarzen Rand z e i c h n e n 14 und mit dem G r a d i e n t e n f ü l l e n. > 15 <r e c t x= 100 y= 200 width= 800 h e i g h t= 600 s t r o k e= b l a c k 16 s t r o k e width= 25 f i l l = u r l (#fade ) /> 17 </ svg> Bild 2.1 auf Seite 9 zeigt die im Browser dargestellte SVG-Datei (vgl. [FLAN2012, S666ff]). Der Vorteil von SVG im Vergleich zu Pixelgrafiken ist, dass man diese sehr einfach per Java- Script verändern kann. JavaScript ist eine Skriptsprache, die die dynamische interaktive Modifikation von Webseiten im Browser ermöglicht (weitere Informationen [KERS2005, S. 855ff]). Beispielhaft soll dazu im soeben generierten Bild 2.1 dynamisch der Farbverlauf geändert werden. Als erstes muss dem Element, das verändert werden soll, eine id zugewiesen werden. Dafür wurde Zeile 9 aus Listing 2.1 wie folgt modifiziert: 8

11 Bild 2.1: SVG Grafik aus Listing 2.1 [FLAN2012, S. 667] 1 <s t o p i d = s t a r t o f f s e t o f f s e t = 0% stop c o l o r = #008 /> Es wurde id="startoffset" hinzugefügt. Jetzt kann auf das Element per JavaScript zugegriffen werden und die Farbe beispielsweise von Blau (#008) auf Grün (#00FF00) geändert werden. 1 v a r s t a r t O f f s e t = document. getelementbyid ( s t a r t o f f s e t ) ; 2 // <s t o p i d = s t a r t o f f s e t o f f s e t = 0% stop c o l o r = #008 /> 3 s t a r t O f f s e t. s e t A t t r i b u t e ( stop c o l o r, #00FF00 ) ; 4 // <s t o p i d = s t a r t o f f s e t o f f s e t = 0% stop c o l o r = #00FF00 /> Nach der Veränderung durch JavaScript sieht das Bild dann wie in Bild 2.2 aus. Bild 2.2: SVG Grafik aus Listing 2.1 nach Modifizierung 9

12 In SVG werden nicht nur Farbverläufe unterstützt, sondern auch grafische Elemente. Dazu zählen Pfade, Kreise, Ellipsen, Rechtecke, Linien, Polygonzüge, Polygone, Texte und Bilder. Ein Pfad besteht aus einer beliebigen Kombination von Strecken, Ellipsebögen, quadratischen und kubischen Bézierkurven (Siehe: [ZIMM2012, S. 92ff]) sowie Neupositionierungen (ausführliche Beschreibung: [PaWiSwSt+2008]). Mit diesen Elementen können komplexe Strukturen definiert werden. SVG ist jedoch ein Dateiformat für zweidimensionale Vektorgrafiken. Es kann nur mit Hilfe von zusätzlichen Bibliotheken wie beispielsweise svg3d (siehe: [DEBE]) eine dritte Dimension hinzugefügt werden. Die komplette Berechnung vom Aufbau der SVG-Datei wird auf der CPU ausgeführt Application-Streaming und Anwendungsserver Die zweite Möglichkeit zur Visualisierung von 3D-Daten ist das Application-Streaming bzw. der Application-Server (Anwendungsserver). Ein Anwendungsserver (Application Server) erlaubt den Benutzern die Verwendung von Anwendungsprogrammen über das Netzwerk, die sich eigentlich auf dem Server befinden (vgl. [KERS2005, S. 557]). Der Datenbestand der Anwendung liegt bei der einfachsten Form des Anwendungsservers auf dem Server. Die Anwendung wird vor der Ausführung über das Netzwerk in den Arbeitsspeicher des Client-Computers geladen und dort lokal ausgeführt. Die nächst komplexere Form ist, Teile des Programms oder auch das komplette Programm auf dem Server auszuführen. Der Client würde dem Benutzer nur die Oberfläche des Programms anzeigen und alle Operationen direkt auf dem Server ausführen (vgl. [KERS2005, S. 557f]). Mit einem Anwendungsserver könnte die aktuelle wxwidgetgui komplett auf dem Server ausgeführt werden und der Benutzer würde nur die Benutzeroberfläche sehen. Es gibt verschiedene Arten der Umsetzung dieser Technologie. Bei einigen davon kommt ein Browser für die Darstellung des Frontends zum Einsatz, bei anderen wird dafür eine spezielle Software benötigt. Weiter ist davon auszugehen, dass die wxwidgetgui ohne Anpassungen an den Anwendungsserver nicht funktionieren wird. Programme für diese Art der Umsetzung sind XenApp (Citrix), App-V (Microsoft) und 2X ApplicationServer XG (2X), um nur einige Beispiele zu nennen. Alle hier genannten sind nur fähig Windows-Applikationen zu verarbeiten und daher nicht für den Prototypen einsetzbar. 10

13 Eine weitere Möglichkeit ist der X-Window-Server bzw. X-Server. Der X-Server stellt den Anwendungsprogrammen seine Dienste zur Verfügung, die darauf zugreifen, um Fenster und andere Komponenten der GUI darzustellen (vgl. [KERS2005, S. 557]). In diesem Szenario würde die wxwidgetgui auf dem Server ausgeführt werden. Der Client würde seinen X-Server dem Server zur Verfügung stellen und dieser die Oberfläche auf dem Client X-Server darstellen. X-Server sind sowohl für Windows (z.b. Xming) als auch für Linux (z.b. XServer) verfügbar WebGL Die dritte und letzte vorgestellte Möglichkeit zur Visualisierung von Daten im Browser ist WebGL (Web Graphics Library). Diese ist eine plattformübergreifende, hardwarebeschleunigte 3D-Grafik-Programmierschnittstelle, die auf der Spezifikation von OpenGL ES 2.0 basiert und im Zusammenspiel mit JavaScript entwickelt wird. Die Khronos Gruppe und Mozilla sind Entwickler des lizenzfreien Standards. Bei der Khronos Gruppe handelt es sich um ein Industriekonsortium, das sich für die Erstellung und Verwaltung von offenen Standards im Multimedia-Bereich auf einer Vielzahl von Plattformen und Geräten einsetzt. Zu den über 100 Mitgliedern zählen unter anderem AMD, Intel, NVIDIA, Google sowie Oracle (vgl. [KHRO2014a]). Als Interface zum Document Object Modell (DOM) wird das HTML5 Canvas Element verwendet. Das Document Object Modell oder DOM ist die grundlegende API für das Arbeiten mit den Inhalten von HTML- und XML-Dokumenten (vgl. [FLAN2012, S. 390]). Für die Verwendung von WebGL im Browser werden keine zusätzlichen Plugins benötigt. Die unterstützten Browser und deren Versionen werden in Tabelle 2.2 aufgelistet. Tabelle 2.2: WebGL Unterstützung, Quelle: [DEVE2014b] Browser Version Aktuelle Version Internet Explorer Mozilla Firefox Google Chrome Apple Safari Opera WebGL kann dazu verwendet werden, aufwändige Grafikanwendungen in den Browser zu integrieren. Beispiele hierfür sind die Visualisierung von Satellitenumlaufbahnen um die 11

14 Erde (Bild 2.3(c)), 3D Welten (Bild 2.3(b)) oder auch nur einige geometrische Formen im Raum (Bild 2.3(a)). (a) Geometrische Formen im Raum [BRAN2014] (b) 3D Welt [BETC2014] (c) Satellitenumlaufbahnen um die Erde [GILL2013] Bild 2.3: Beispiele für Grafikanwendungen im Browser Um WebGL im Browser zu nutzen können grundlegend zwei Ansätze verfolgt werden: Reines WebGL WebGL-Bibliotheken Bei der Verwendung von reinem WebGL stehen dem Entwickler alle WebGL API Funktionen des Browsers zur Verfügung. Alternativ dazu kann eine WebGL-Bibliothek verwendet werden, wovon bereits eine Vielzahl existiert. Die Khronos Gruppe hat eine Liste mit allen bekannten WebGL-Bibliotheken 12

15 erstellt. Diese beinhaltet 34 Bibliotheken, wovon jede eine unterschiedliche Zielgruppe besitzt (siehe: [KHRO2013a]). Manche davon können ausschließlich Dateien aus anderen Programmen importieren und darstellen, während andere nur eine sehr rudimentäre Funktionalität besitzen. Die Bekanntesten sind: GLGE (Abgerufen: ) SceneJS (Abgerufen: ) CubicVR (Abgerufen: ) Three.js (Abgerufen: ) Die in diesem Projekt verwendete Bibliothek heißt Three.js und wurde von Ricardo Cabello Miguel entwickelt. Three.js bietet eine einfache, intuitive Ansammlung von Objekten und Funktionen, die (auch normalerweise) im Bereich der 3D-Grafik angesiedelt sind. Durch die Verwendung von vielen best-practice Grafik-Engine-Techniken wird Three.js zu einer sehr schnellen Bibliothek. Weiterhin sind viele Helfer-Funktionen und Standard-Objekte bereits implementiert. Es handelt sich bei Three.js um ein Open-Source-Projekt, das auf GitHub ([CABE2014b]) liegt und sehr gut durch Ricardo Cabello Miguel und diverse andere Autoren gepflegt wird. GitHub ist ein Hosting-Dienst für Software-Projekte, als Versionsverwaltungssystem kommt Git zum Einsatz. Das Projekt ist unter der MIT Lizenz veröffentlicht. Weitere Vorteile von Three.js sind: Verbergen der Details des 3D-Rendering. Abstraktion der einzelnen Aufrufe der WebGL API, so dass der Benutzer nur mit Gittern, Materialien und Lichtern arbeiten muss. Die Bibliothek ist objektorientiert aufgebaut. Unterstützung von Benutzerinteraktion. WebGL bietet keine native Möglichkeit für das Auswählen von Objekten im 3D Raum. Three.js hingegen biete volle Unterstützung. (vgl. [PARI2012, S. 17ff]) Weitere Informationen und eine Implementierung sind in Kapitel 4.2 auf Seite 46 zu finden. 13

16 2.1.4 Zwischenfazit Visualisierung In diesem Kapitel wurden die grundlegenden Technologien für die Visualisierung von 3D- Daten im Web vorgestellt. Zunächst wurden die verschiedenen Möglichkeiten erklärt 3D- Daten auf einem PC im Browser oder per Anwendung zu visualisieren. Ein Anwendungsserver stellt eine gute Möglichkeit dar, Applikationen über das Netzwerk auszuführen. Von den verschiedenen vorgestellten Möglichkeiten ist der X-Server die vielversprechendste. Da diese Technologie aber nicht im Browser und somit nicht im Web läuft, wird diese in der vorliegenden Arbeit nicht verwendet. SVG ist ebenso ein Ansatz, um die Visualisierung von 3D-Daten im Browser zu ermöglichen. Der Vorteil ist hierbei, dass sowohl auf PCs als auch auf Tablets die Unterstützung von SVG durch den Browser vorhanden ist. Dafür müssen allerdings Berechnungen für die darzustellenden Elemente, deren Rotation, Farbe und Transparenz komplett auf der CPU ausgeführt werden. Das kann zu hoher Last auf dem Client führen. Die Grafikkarte wird hierbei leider nicht verwendet. Ebenso ist SVG ein Dateiformat für 2D-Dateien und kann nur mit Hilfe einer zusätzlichen Bibliothek um die dritte Dimension erweitert werden. WebGL ist der letzte und wohl vielversprechendste Ansatz. Der Vorteil besteht darin, dass alle Berechnungen den 3D-Raum betreffend auf der Grafikkarte ausgeführt werden. Das führt zu einem großen Gewinn an Performance, im Vergleich zur reinen Ausführung auf der CPU. Ebenso wird die CPU entlastet und kann für andere Aufgaben verwendet werden. Durch die Verwendung von einer WebGL-Bibliothek wird das Entwickeln von Anwendungen mit WebGL deutlich vereinfacht. Durch eine höhere Abstraktionsstufe der WebGL API wird es möglich, WebGL als objektorientierte Bibliothek und nicht nur als Ansammlung von API-Funktionen zu nutzen. Aufgrund der Einfachheit und Erweiterbarkeit wurde WebGL den Alternativen Application- Streaming und SVG vorgezogen und wird in diesem Projekt verwendet. 2.2 HTML5 HTML5 ist eine der beiden Technologien, die die Grundlage für den Prototypen bilden. HTML5 ist die Bezeichnung für die neueste Version der HTML-Spezifikation, hat sich aber 14

17 auch zu einem Begriff für einen ganzen Satz von Technologien für Webanwendungen entwickelt, die als Teil von oder neben HTML (Hypertext Markup Language) entwickelt und in der Spezifikation festgehalten wurden (vgl. [FLAN2012, S. 712]). Eins dieser Elemente ist das HTML5 Canvas Element. Dieses stellt die Umgebung für das Zeichen zur Verfügung. Diese Umgebung bildet die Grundlage für WebGL (Siehe Kapitel auf Seite 11). Ein weiteres Element ist WebSocket, welches bidirektionale Verbindungen im Browser ermöglicht (Siehe Kapitel auf Seite 19). 2.3 JSON JSON ist die zweite der beiden Technologien, die die Grundlage für den Prototypen bilden. JSON steht für JavaScript Object Notation und ist ein Serialisierungsformat für Daten, das auf JavaScript-Literalen basiert und den Wert null, die boolschen Werte true und false, Gleitkommazahlen, Strings (Zeichenketten), Arrays mit Werten und String/Wert- Zuordnungen beherrscht. Der elementare Wert undefined und die numerischen Werte NaN (Not a Number) und Infinity können mit JSON nicht dargestellt werden. Auch JavaScript-Funktionen, Date-, RegExps- und Error-Objekte werden nicht unterstüzt (vgl. [FLAN2012, S. 841]). Eine beispielhafte Verwendung von JSON in JavaScript sieht wie folgt aus: 1 // T e s t o b j e k t d e f i n i e r e n 2 v a r t e s t O b j e k t = {a : 1, b : { c : [ foo, n u l l ] }, d : f a l s e } ; 3 4 v a r s = JSON. s t r i n g i f y ( t e s t O b j e k t ) ; 5 // s i s t { a : 1, b : { c : [ foo, n u l l ] }, d : f a l s e } 6 7 v a r p = JSON. p a r s e ( s ) ; 8 // p i s t e i n e t i e f e Kopie von t e s t O b j e k t 2.4 Datenübertragung zwischen Server und Browser In diesem Kapitel werden die verschiedenen Möglichkeiten zur Dateiübertragung zwischen Server und Browser verglichen. Diese werden anschließend für die Kommunikation zwischen dem FEMCore und der WebGUI verwendet. Zuerst werden die GET- und POST 15

18 Anfrage, dann das (long) polling und abschließend Websocket vorgestellt. HTTP steht für Hypertext Transfer Protocol (Hypertext-Übertragungsprotokoll). Es handelt sich dabei um das Netzwerkprotokoll zur Übertragung von Daten im Internet. Dabei ist es egal, ob es sich bei den Daten um Bilder, HTML-Dateien, 3D-Daten oder jegliche andere Art von Daten handelt. Diese Daten werden allgemein zu Ressourcen zusammengefasst. Meistens werden die Dateien über eine TCP/IP Socket Verbindung übertragen, allerdings ist auch UDP möglich. TCP/IP steht für Transmission Control Protocol; ein zuverlässiges Transportprotokoll der Internet-Protokollfamilie (vgl. [KERS2005, S. 1001]). UDP steht für User Datagram Protocol; ein schnelles, verbindungsloses Transportprotokoll der Internet-Protokollfamilie (vgl. [KERS2005, S. 1002]). HTTP nutzt wie die meisten Netzwerkprotokolle ein Client-Server-Modell, wobei es sich um ein zustandsloses Protokoll handelt; es werden keine Informationen über die vergangenen Verbindungen erhalten. Ein HTTP-Client öffnet die Verbindung zum Server und sendet eine Nachricht an diesen. Diese Nachricht enthält die Ressource, die vom Server abgefragt werden soll, und wird auch als request message bezeichnet. Der Server antwortet darauf mit der angeforderten Ressource in einer sogenannten response message. Nach dem Abschluss der Übertragung vom Server zum Client schließt der Server die Verbindung zu diesem. Die Anfrage an den Server kann einen der drei folgenden Befehle beinhalten: GET POST HEAD GET und POST werden im nächsten Kapitel weitergehend erklärt, HEAD ist für die Dateiübertragung nicht von Interesse. (vgl. [JAME2012]) GET- und POST-Anfragen Sowohl GET- als auch POST-Anfragen bestehen aus zwei Teilen: Kopfzeile (Header) und Inhalt (Body). In HTTP 1.0 können bis zu 16 und in HTTP 1.1 bis zu 46 Header angegeben werden. Bei HTTP 1.1 wird mindestens der Header Host: benötigt, bei HTTP 1.0 nicht. Da es sich bei HTTP 1.1 um den aktuellen Standard handelt, werden alle weiteren Beispiele und Erklärungen auf diesen beschränkt. Bei einer GET-Anfrage ist es meistens das Ziel Daten vom Server abzufragen, beispielsweise ein HTML Dokument. Eine GET-Anfrage für die Datei /pfad/datei.html auf dem Server würde wie folgt aussehen: 16

19 1 GET / pfad / d a t e i. html HTTP/1.1 2 Host : www. t e s t h o s t. de Es wird also das Kommando GET zusammen mit den Headern gesendet. In diesem Beispiel wird nur ein Header übertragen. Eine GET-Anfrage enthält keinen Inhalt (Body). Es werden also keine weiteren Daten nach den Kopfzeilen mehr angehängt. Um Daten an den Server zu übergeben, wird die URL nach dem Kommando GET erweitert. Es wird ein? und danach Schlüssel/Wert-Paare & -separiert angefügt. Eine GET-Anfrage für die Datei /pfad/datei.php auf dem Server mit den Parametern name1 und name2 und den Werten wert1 und wert2 sieht wie folgt aus: 1 GET / pfad / d a t e i. php?name1=wert1&name2=wert2 HTTP/1.1 2 Host : www. t e s t h o s t. de Die Länge der Daten ist auf die maximal mögliche Länge der URL beschränkt. Dieser Wert liegt zwischen 255 und üblicherweise 8192 Bytes, kann aber auf dem Webserver eingestellt werden (vgl. [FiGeMoFr+1999, S. 14 (3.2.1)]). Die POST-Anfrage ist für das Übertragen von (Form-)Daten zu einem Server gedacht. Anders als bei der GET-Anfrage werden die Daten im Body übertragen und nicht in die URL kodiert. Üblich sind auch weitere Header wie Content-Type und Content-Length neben dem Host Header. Außerdem wird mit einer POST-Anfrage eher selten eine HTML Datei abgefragt. Es wird meistens ein Skript auf dem Server aufgerufen, beispielsweise ein PHP- Skript, das die übergebenen Daten dann verarbeitet. PHP ist ein rekursives Akronym für PHP:Hypertext Preprocessor; eine verbreitete Sprache für serverseitige Web-Anwendungen ([KERS2005, S. 999]). Eine POST-Anfrage für die Datei /pfad/datei.php auf dem Server mit den Parametern name1 und name2 und den Werten wert1 und wert2 sieht so aus: 1 POST / pfad / d a t e i. php HTTP/1.1 2 Host : www. t e s t h o s t. de 3 Content Type : a p p l i c a t i o n /x www form u r l e n c o d e d 4 Content Length : name1=wert1&name2=wert2 Die Länge der Daten ist durch eine Einstellung im Webserver begrenzt. (vgl. [JAME2012]) Es können also sowohl mit einer GET- als auch mit einer POST-Anfrage Daten vom Client an den Server übertragen werden. Der Server kann jedoch nur mit dem Client kommunizieren, wenn dieser eine Anfrage an den Server sendet. Daraus folgt, dass, wenn der Server 17

20 Daten für den Client hat, dieser immer warten muss, bis sich der Client das nächste Mal mit ihm verbindet. Eine Lösung für dieses Problem ist das (long) polling, womit sich das nächste Kapitel beschäftigt (Long) Polling Eine erste mögliche Lösung für dieses Problem wäre das Pollen des Webservers (Siehe: Bild 2.4). Dabei verbindet sich der Client zum Server und dieser sendet gegebenenfalls bereitstehende Daten an den Client. Falls keine Daten vorhanden sind, wird die Verbindung geschlossen. Der Client überprüft somit periodisch, ob neue Inhalte vom Server verfügbar sind. Eine zweite Lösung für dieses Problem ist das sogenannte long polling (Siehe: Bild 2.5). Hierbei wird eine Anfrage an den Server gesendet, welcher die Verbindung bis zum Timeout geöffnet lässt. Anschließend sendet der Client Bild 2.4: Polling eine neue Anfrage an den Server. Das führt dazu, dass eine durchgehende Verbindung zwischen Server und Client besteht und beide Parteien Daten senden und empfangen können, wenn es nötig ist. Dies jedoch führt zu einer Vielfalt von neuen Problemen: Der Server ist gezwungen, eine Vielzahl von TCP Verbindungen für jeden Client zu unterhalten: eine Verbindung wird zum Senden an den Client benötigt. Für jede ankommende Nachricht vom Client je eine weitere. Es wird ein hoher Overhead produziert, da jede Nachricht einen Header enthält. Der Client muss eine Zuordnung von ausgehenden zu eingehenden Verbindungen erstellen, um die Antworten korrekt zuordnen zu können. Eine einfachere Lösung für dieses Problem wäre eine einzelne TCP Verbindung, die für die Kommunikation in Bild 2.5: Long-Polling 18

21 beide Richtungen verwendet wird. Eine solche Möglichkeit bietet das WebSocket-Protokoll, welches im nächsten Kapitel thematisiert wird. (vgl. [FEME2011, S. 5ff] und [WEßE2011, S. 1f]) WebSocket Das WebSocket Protokoll bietet eine einfache Möglichkeit, eine bidirektionale Verbindung zwischen Webanwendungen und einem WebSocket- oder einem Web-Server herzustellen. Der Web-Server muss hierbei das WebSocket Protokoll unterstützen. In Kombination mit der WebSocket API wird damit eine Alternative zum HTTP Polling für eine bidirektionale Kommunikation zur Verfügung gestellt. Das Protokoll wurde so entworfen, dass es bestehende bidirektionale Kommunikationstechnologien, die HTTP als Transport-Schicht nutzen, ablösen kann. WebSocket verwendet die Standard-HTTP-Ports 80 und 443 für TLS (Transport Layer Security; deutsch Transportschichtsicherheit), sodass der Verbindungsaufbau auch durch Firewalls hinweg funktioniert. Dabei sollen alle Vorteile der aktuellen Infrastruktur (Proxies, Filtering, Authentifizierung) weiter genutzt werden können. Alternativ dazu könnte eine andere Transportschicht (OSI-Modell Schicht 4 (siehe: [KERS2005, S. 543ff]) wie zum Beispiel TCP/IP oder UDP verwendet werden. Der Vorteil von HTTP als Transportschicht besteht darin, dass zwar die Implementierung um die WebSocket Funktionalität erweitert werden musste, aber der Handshake von HTTP übernommen werden kann. Durch einen Handshake werden die Parameter für den Kommunikationskanal zwischen Client und Server ausgehandelt. Ebenso ist es hierdurch möglich, sowohl HTTP(S) als auch WebSocket auf einem Server auf dem gleichen Port (80 oder 443) laufen zu lassen. Handshake und Datentransfer sind die zwei Teile des WebSocket Protokolls. Der Handshake ähnelt der GET-Anfrage von HTTP und wird in Listing 2.2 gezeigt. Listing 2.2: Handshake vom Client 1 GET / chat HTTP/ Host : s e r v e r. example. com 3 Upgrade : websocket 4 Connection : Upgrade 5 Sec WebSocket Key : dghlihnhbxbszsbub25jzq== 6 O r i g i n : h t t p : / / example. com 7 Sec WebSocket P r o t o c o l : chat, s u p e r c h a t 8 Sec WebSocket V e r s i o n : 13 19

22 Der Eröffnungs-Handshake ist so entworfen, dass er mit HTTP-Web-Servern kompatibel ist und somit sowohl HTTP Clients als auch WebSocket Clients mit dem gleichen Server über einen Port kommunizieren können. Als Parameter für den GET Befehl wird der Pfad zum WebSocket Endpunkt (Ressource) übergeben (Hier /chat). Wie bei der GET-Anfrage ist der Host Header zwingend notwendig. Dazu kommen die zwei neuen Header Upgrade und Connection, die dem Server mitteilen, dass der Client ein Upgrade auf das WebSocket- Protokoll durchführen möchte. Sec-WebSocket-Key kommt außerdem als Header hinzu und wird für das Akzeptieren des Verbindungsaufbaus verwendet. Alle anderen Header sind optional. Weitere Header werden genutzt, um Optionen für das WebSocket Protokoll zu definieren. Der Header Origin enthält die Quelle der Anfrage. Falls der Server den Origin akzeptiert, wird eine Nachricht an den Client gesendet, dass die Verbindung akzeptiert wurde. Um dem Client zu zeigen, dass sein und nicht irgendein anderer Handshake akzeptiert wurde, wird eine Nachricht für den Client aus zwei Komponenten generiert. Die erste Komponente ist der Sec-WebSocket-Key, der mitgesendet wird. Dieser wird mit dem Globally Unique Identifier (GUID) 258EAFA5-E914-47DA- 95CA-C5AB0DC85B11 verkettet. Aus dieser verketteten Zeichenkette wird dann ein SHA-1 Hash (siehe [EaJo2001]) generiert, welcher anschließend base64 (siehe [BRUE2003]) kodiert wird. Das Ergebnis aus diesen Operationen Bild 2.6: WebSocket Kommunikation wird dann dem Handshake als Header Sec- WebSocket-Accept beigefügt. Ebenso wird eins oder keins der Protokolle aus dem Client Handshake Header Sec-WebSocket-Protocol im Server Handshake Header Sec-WebSocket- Protocol beigefügt. Der komplette Server Handshake wird in Listing 2.3 dargestellt. Listing 2.3: Handshake vom Server 1 HTTP/ S w i t c h i n g P r o t o c o l s 2 Upgrade : websocket 3 Connection : Upgrade 4 Sec WebSocket A c c e p t : s3pplmbitxaq9kygzzhzrbk+xoo= 20

23 5 Sec WebSocket P r o t o c o l : chat Nach dem erfolgreichen Handshake können sofort Daten übertragen werden (vgl. [FEME2011, S. 5ff] und [WEßE2011, S. 2]). Nachrichten werden bei WebSockets in Frames übertragen (siehe Bild 2.6 auf Seite 20)(weitere Informationen [RONA2012, Framing]) Zwischenfazit Datenübertragung Der zweite große Bereich dieses Kapitels handelt von der Übertragung der Daten vom Client zum Server und umgekehrt. Hier wurden HTTP(S) und dessen POST- und GET-Request mit WebSocket verglichen. Da WebSocket die Weiterentwicklung von HTTP ist (wie oben beschrieben) und mit der Verwendung von WebSocket keine Lösungen wie (long) polling verwendet werden müssen, um eine bidirektionale Kommunikation zu erlangen, wurde WebSocket als Form der Übertragung gewählt. Das bringt außerdem den Vorteil, dass auf Serverseite nur ein WebSocket-Server und kein vollständiger HTTP-Server implementiert werden muss. Gerade die bidirektionale Kommunikation ist der ausschlaggebende Punkt, warum WebSocket der Alternative vorgezogen und in diesem Projekt verwendet wurde. Nachdem die Technologien für die Umsetzung feststehen, kann mit der Anforderungsanalyse für den Prototypen begonnen werden (Kapitel 3 auf Seite 24). Vorher werden jedoch noch die Echtzeit- und Performance-Anforderungen für Webapplikationen im folgenden Kapitel vorgestellt. 21

24 2.5 Echtzeit- und Performance-Anforderungen für Webapplikationen Hier werden die Echtzeit- und Performance Anforderungen für Webapplikationen und damit den Prototypen angerissen. Dabei wird versucht, diese Anforderungen basierend auf den Anforderungen für Desktop-Applikationen herzuleiten. Die erste Frage ist: Was ist Echtzeit? Die DIN definiert Echtzeit wie folgt: Unter Echtzeit versteht man den Betrieb eines Rechensystems, bei dem Programme zur Verarbeitung anfallender Daten ständig betriebsbereit sind, derart, dass die Verarbeitungsergebnisse innerhalb einer vorgegebenen Zeitspanne verfügbar sind. Die Daten können je nach Anwendungsfall nach einer zeitlich zufälligen Verteilung oder zu vorherbestimmten Zeitpunkten anfallen. (Siehe [SCHO2005, S. 39]) Im Duden sind zwei Beschreibungen für die Echtzeit zu finden: (EDV) vorgegebene Zeit, die bestimmte Prozesse einer elektronischen Rechenanlage in der Realität verbrauchen dürfen und simultan zur Realität ablaufende Zeit (vgl. [BIBL2013a]). Ebenfalls im Duden findet man die folgende Definition für Echtzeitbetrieb: Arbeitsweise einer elektroni- schen Rechenanlage, bei der das Programm oder die Datenverarbeitung (nahezu) simultan mit den entsprechenden Prozessen in der Realität abläuft (vgl. [BIBL2013b]). Man kann also sagen, dass ein Programm, das in Echtzeit läuft, immer eine bestimmte Aufgabe in einer bestimmten Zeit zu erledigen hat. Generell kann die Echtzeit noch in zwei Unterkategorien aufgeteilt werden: die harte und die weiche Echtzeit. Bei der harten Echtzeit ist es ausschlaggebend, dass die definierte Aufgabe ohne Ausnahmen in dem dafür vorgesehenen Zeitraum ausgeführt wird. Ein Beispiel hierfür wäre eine elektronische Motorsteuerung, bei deren Versagen es zum Schaden oder sogar Ausfall des Motors kommen kann. Im Gegensatz zur harten Echtzeit kann es bei der weichen Echtzeit durchaus vorkommen, dass die Ausführung der Aufgabe etwas länger dauert als geplant. Der vorgegebene Zeitraum kann hier mehr als eine Art Richtlinie statt einer festen Vorgabe angesehen werden. Im Web können die Anforderungen für Desktop-Applikationen nur teilweise übernommen werden. Die grafische Benutzeroberfläche (GUI) von sowohl Web- als auch Desktop-Applikationen haben vieles gemeinsam. Beide sollen möglichst sofort reagieren, wenn der Benutzer mit diesen interagiert. Es darf zum Beispiel nicht der Fall sein, dass ein Button 22

25 geklickt wird und der Benutzer mehrere Sekunden auf das zu öffnende Fester warten muss (das kann natürlich vorkommen, sollte aber nicht der Regelfall sein). Da aber durchaus Antwortzeiten von bis zu einer Sekunde für einfache, zwei bis vier Sekunden für normale und acht bis zwölf Sekunden komplexe Aufgaben vom Benutzer als akzeptabel angesehen werden, handelt es sich hierbei um weiche Echtzeit (vgl. [HoDi2000, S. 23]). Im Gegensatz hierzu steht die Anbindung von Programm-Komponenten. Beispielsweise wird eine C++-Bibliothek betrachtet, die das Backend darstellt. Bei einer klassischen Desktop Applikation kann die grafische Benutzeroberfläche auch in C++ geschrieben und anschließend das Backend angebunden werden. Es kann so direkt und ohne Verzögerung auf alle Funktionen des Backends zugegriffen werden. Soll die GUI jedoch ins Web portiert werden, so ist es nicht mehr möglich, ohne Verzögerung auf das Backend zuzugreifen. Es muss mindestens die Zeit hinzuaddiert werden, die benötigt wird, um über eine beliebig geartete Schnittstelle mit dem Backend zu kommunizieren. Hier wird der erste Unterschied zwischen einer Desktop- und einer Web-Anwendung, was die Echtzeit betrifft, deutlich. Während es bei der Desktop-Anwendung möglich ist sofort auf das Backend zuzugreifen, kann bei der Web-Variante je nach Art der Schnittstelle eine zusätzliche Verzögerung auftreten. Auch hier handelt es sich um weiche Echtzeit. Die Anforderungen an die Performance für Web Applikationen bleiben dennoch die gleichen wie bei Desktop Applikationen: es soll möglichst schnell auf Funktionen zugegriffen werden können. Dabei ist es unwichtig, ob es sich um Funktionen für die GUI in JavaScript handelt oder um Funktionen - in welcher Sprache auch immer - auf dem Server, mit dem über das Internet, Intranet oder dem lokalen Computer kommuniziert wird. Ein weiterer Aspekt die Performance betreffend ist auch, dass es sich bei JavaScript um eine Interpreter-Sprache handelt. Der Code wird erst beim Laden der Website in Maschinensprache übersetzt und anschließend während der Ausführung immer weiter optimiert (Funktionsweise bei der V8 JavaScript-Engine von Google; bei anderen Browsern evtl. abweichend (vgl. [GOOG2014]). Im Gegensatz zu einer Desktop-Anwendung ist das natürlich ein deutlicher Nachteil. Diese Art von Anwendung wird bereits bevor sie ausgeführt wird kompiliert. Der Code kann somit vorher bereits beispielsweise durch den Compiler auf Geschwindigkeit optimiert werden. Für die Visualisierung von Daten gilt, dass diese mit mindestens 25 Bildern pro Sekunde (FPS) dargestellt werden müssen. Ab dieser Anzahl von Bilder sieht das menschliche Auge eine Bewegung / bewegte Bilder (Videos, Animationen) als flüssig an. Weitere Anforderungen für die Visualisierung von Daten neben den 25 FPS sind nicht vorhanden. 23

26 3 Anforderungsanalyse für den Prototypen In diesem Kapitel werden die Anforderungen für den Prototypen ermittelt. Dieser ist aus der wxwidgetgui aus dem Projekt SimCloud abgleitet und wird als WebGUI bezeichnet. Das Kapitel ist unterteilt in zwei Bereiche. Zuerst werden die Anforderungen vorgestellt und anschließend die abgeleitete Software- und Systemarchitektur. 3.1 Anforderungen Die Anforderungen an die WebGUI lassen sich aus den Anforderungen der wxwidgetgui ableiten. Die Anforderungen sind unterteilt in Bedienungsanforderungen (Kapitel 3.1.1) und Datenmenge und Performance (Kapitel 3.1.2) Bedienungsanforderungen Die Applikation besteht aus fünf Elementen und passt sich damit dem Aussehen der wx- WidgetGUI aus Bild 3.1 auf Seite 25 an. Menüleiste Oben WebGL-Fenster Mitte rechts Projektbaum Mitte links Fehlerkonsole Zusätzliche Komponente Simulationsfortschrittsbalken Zusätzliche Komponente Die Anforderungen an das Laden, Speichern und die Exportvorgänge sind die Folgenden: Es kann eine STL Datei geladen werden und die Fehlermeldungen werden in der grafischen Benutzeroberfläche angezeigt. Alternativ kann auch eine gmsh- oder netgen- Datei geladen werden. Der Benutzer kann vor dem Laden einer Datei auswählen, ob es sich um eine gmshoder netgen-datei handelt. 24

27 Bild 3.1: wxwidgetgui aus dem Projekt SimCloud Die aktuelle Ansicht kann als PNG Datei exportiert werden. Die Anforderung an die Interaktion mit dem Gitter sind die Folgenden: Es ist möglich, die Kamera frei im Raum zu bewegen mittels WASD-Ansatz und +/- für das Zoomen. Der WASD-Ansatz ist ein aus Computerspielen bekannter Ansatz zur Navigation durch eine 3D-Welt. Alternativ soll die Kamera frei im Raum durch das Bewegen der Maus und Zoomen durch das Mausrad bewegt werden. Es ist möglich, einzelne Elemente mit einem Klick mit der linken Maustaste (LMT) auszuwählen (Bild 3.2 auf Seite 26). Es ist ebenso möglich, mehrere Elemente mit zusätzlichem Halten der STRG-Taste auszuwählen. Mit einem Klick mit der rechten Maustaste (RMT) können Aktionen mit den ausgewählten Punkten ausgeführt werden. Bedaten eines oder mehrerer Punkte Informationen über einen Punkt Informationen zur Lösung eines Punktes 25

28 Bild 3.2: Einzelnes Element ausgewählt Ausblenden eines oder mehrerer Punkte Bild 3.3(a) und 3.3(b) auf Seite 27 zeigen einen Entwurf für den Aufbau des Fensters, um ein Problem bzw. die Randwerte in der WebGUI zu definieren. Die weiteren Anforderungen sind: Es stehen Dialoge zur globalen Bedatung zur Verfügung. Es können analytische Funktionen als Parameter angegeben werden, die durch das Backend auf Fehler überprüft werden. Dirichlet- und Neumann-Randwerte stehen in der GUI zur Bedatung zur Verfügung. Anforderungen an die Auswahl von Parametern für die Simulation: Es ist möglich, die Simulation zu starten. Bild 3.4 auf Seite 27 zeigt einen Entwurf für den Aufbau des Fensters für die Hardwaredaten. Die weiteren Anforderungen sind: Es wird eine Liste mit allen verfügbaren (Cloud-) Servern angezeigt. Es kann pro Server die Anzahl der benötigten Prozessoren ausgewählt werden. 26

29 (a) Problem definieren (b) Randwerte definieren Bild 3.3: Problem und Randwerte definieren Bild 3.4: Entwurf des Hardware-Dialogs Es kann ein underlying problem aktiviert werden und es steht anschließend On Host oder On an external cloud zur Auswahl. Anforderung an die Visualisierung von Gittern ohne vorliegende Lösung: Ein geladenes Gitter kann als reines Gittermodell (nur Linien) dargestellt werden. Anforderung an die Visualisierung von Lösungswerten: Skalare Werte Anforderungen an die Fehlerkonsole: zeigt Fehler und Warnungen an, die auftreten können zeigt möglichst viele Informationen zum Simulationsverlauf an 27

30 3.1.2 Datenmenge und Performance In diesem Kapitel werden die Anforderungen an die Datenmenge für den Prototypen zusammengetragen. Bei den analysierten Datenmengen handelt es sich ausschließlich um die Daten, die zwischen Client und Server übertragen werden. Weitergehend wird auch die Performance mit in die Betrachtung einbezogen. Als Grundlage für die Berechnungen werden die Upload- und Download-Geschwindigkeiten aus Tabelle 3.1 verwendet (Quelle: [TCOM2014]). Tabelle 3.1: Up- und Download Geschwindigkeit von DSL 6000 bis VDSL 50 Download Upload Beschreibung [kbit/s] [kbyte/s] [kbit/s] [kbyte/s] DSL DSL VSDL VSDL Zusätzlich werden die vier Gitterdateien aus Tabelle 3.2 für diesen Test generiert. Dafür wird die Datei shaft.vol so lange mit dem Gitter-Generator Netgen (Weitere Informationen: [SCHO2014]) verfeinert, bis die gewünschte Anzahl der Elemente erreicht ist (hier 10 6 Elemente). Tabelle 3.2: Eigenschaften der Gitterdateien für den Performance-Test Dateiname Anzahl der Elemente Dateigröße [kb] shaft.vol shaft 20k.vol shaft 167k.vol shaft 1.3m.vol Für die weitergehenden Berechnungen wird von einem Benutzer mit DSL 6000 bis einschließlich VDSL 50 ausgegangen. Die Übertragung der Dateien vom Client zum Server kann berechnet werden, indem die Größe der verschiedenen Dateien aus Tabelle 3.2 durch die Upload-Geschwindigkeit aus Tabelle 3.1 geteilt wird. Das Ergebnis dieser Berechnung(en) ist in Tabelle 3.3 auf Seite 29 dargestellt. 28

31 Tabelle 3.3: Übertragungsdauer der Gitter-Datein (Tabelle 3.2) zum Server Dauer [s] Dateiname DSL 6000 DSL VDSL 25 VDSL 50 shaft.vol 5,16 3,02 0,60 0,30 shaft 20k.vol 26,45 15,50 3,10 1,55 shaft 167k.vol 167,67 98,24 19,65 9,82 shaft 1.3m.vol 1193,67 699,41 139,88 69,84 Basierend auf der Dauer für den Upload der verschiedenen Dateien sind die Anforderungen an den Upload auch davon abhängig, welche Probleme der Benutzer primär bearbeiten möchte. Falls nur Probleme mit weniger als Elementen bearbeiten werden sollen, reicht DSL 6000 aus. Es müsste allerdings eine Übertragung von bis zu drei Minuten vom Benutzer als akzeptabel angesehen werden. Für Benutzer, die hauptsächlich mit großen Problemen (im Bereich 10 6 ) arbeiten, sollte mindestens VDSL 25 zur Verfügung stehen, da sonst Upload Zeiten von bis zu 10 (DSL 16000) bzw. 20 (DSL 6000) Minuten durchaus wahrscheinlich wären. Damit ist die Anforderung für das Projekt, nur aus Sicht des Uploads betrachtet, DSL 6000 oder mehr, abhängig von der Geduld des Benutzers. Als nächstes wird die Download-Dauer für die verschiedenen Dateien berechnet. Dafür werden die Werte in der Optimierung D aus Tabelle 4.2 (Seite 44) verwendet. Aus Gründen der Übersichtlichkeit sind die Werte noch einmal in Tabelle 3.4 aufgeführt. Tabelle 3.4: Größe der Antworten der verschieden Dateien Dateiname Optimierung D [MB] shaft.vol 1,01 shaft 20k.vol 8,08 shaft 167k.vol 63,11 shaft 1.3m.vol 501,88 Auch hier berechnet sich die Übertragungszeit, indem man die Dateigröße aus Tabelle 3.4 durch die Download-Geschwindigkeit aus Tabelle 3.1 auf Seite 28 teilt. Das Ergebnis dieser Berechnung(en) ist in Tabelle 3.5 auf Seite 30 dargestellt. 29

32 Tabelle 3.5: Übertragungsdauer der Gitter-Dateien (Tabelle 3.4) zum Client Dauer [s] Dateiname DSL 6000 DSL VDSL 25 VDSL 50 shaft.vol 1,46 0,55 0,35 0,17 shaft 20k.vol 10,74 4,04 2,58 1,26 shaft 167k.vol 83,92 31,56 20,14 9,82 shaft 1.3m.vol 667,39 250,94 160,19 78,13 Wie bereits bei der Upload-Dauer kann auch hier wieder in zwei Bereiche unterteilt werden. Arbeitet ein Benutzer hauptsächlich mit kleinen Problemen bis maximal Elementen, reicht auch hier, wie beim Upload, DSL 6000 aus. Werden größere (Im Bereich 10 6 ) Probleme bearbeitet, sollte auch hier mindestens VDSL 25 zur Verfügung stehen. Wenn jetzt der Up- und der Download zusammengenommen werden, kann man festlegen: es wird mindestens DSL 6000 für kleinere und VDSL 25 für größere Probleme benötigt. Zu der Dauer für die Simulation an sich können noch keine Aussagen gemacht werden, da diese Funktion noch nicht vollständig im Backend implementiert ist. Die Anforderungen an das Zeichnen der Daten nach dem Empfangen sind relativ kurz. Nachdem die Daten vollständig empfangen sind, sollen diese möglichst schnell für den Benutzer zur Bearbeitung bereit sein. Bei kleineren Gittern sollten daher nicht mehr als zwei Sekunden vergehen, in denen das komplette Gitter erstellt und anschließend für den Benutzer sichtbar dargestellt wird. Bei größeren Gittern sollte ein Maximum von zwölf Sekunden nicht überschritten werden (vgl. [HoDi2000, S. 23]). Diese Werte können natürlich je nach Hardware des Client PC stark variieren. Es bietet sich an, einen Fortschritt für den Nutzer anzuzeigen, um die verbleibende Zeit abschätzen zu können. Für die folgenden Aktionen sollte die gewünschte Aktion (nach Möglichkeit) gefühlt sofort ausgeführt werden: Ein- und Ausblenden von Elementen (Transparent schalten) Auswählen von einzelnen Elementen (Bedatung / Ausblenden) Auswählen von mehreren Elementen (Bedatung / Ausblenden) 30

33 3.1.3 Sicherheit Ein Ziel des Projekt SimCloud ist, eine Cloud-Anwendung zu erzeugen, die einen hohen Anspruch an Sicherheit hat. Da mit dieser Software unternehmenskritische Dateien (beispielsweise das Layout des neuen Türschlosses, das der Konkurrent nicht kennen darf) erst auf den Hauptserver und von dort aus in kleineren Teilen auf die Cloud-Server verteilt werden, ist es besonders wichtig, dass der komplette Weg vor Angriffen geschützt ist. Die Verbindung zwischen Hauptserver und den Cloud-Servern ist hier eher unkritisch, da das zu lösende Problem in kleine Einzelprobleme zerlegt wird und nur die Berechnung an die Cloud-Server delegiert wird. Die Verbindung vom Arbeitsplatz PC (Client) zum Hauptserver hingegen ist durchaus relevant. Die erste Möglichkeit, die Sicherheit zu gewährleisten, wäre den Hauptserver in das Unternehmensnetzwerk via z.b. VPN Strecke aufzunehmen. Dies würde sicherstellen, dass die Daten, die an den Server gesendet werden, komplett durch einen gesicherten Tunnel übertragen werden. Die zweite Möglichkeit besteht darin, die komplette Kommunikation zwischen Client und Hauptserver zu verschlüsseln. Das WebSocket-Protokoll unterstützt verschlüsselte Verbindungen (TLS-Verbindungen) zwischen Client und Server. Durch die Aktivierung dieser Funktion im FEMInterface kann die Sicherheit der Übertragung sichergestellt werden. 31

34 3.2 Abgeleitete Software- und Systemarchitektur In diesem Kapitel wird die Software- und Systemarchitektur für den Prototypen vorgestellt. Diese wird aus der Architektur der wxwidgetgui abgeleitet, welche bereits alle relevanten Komponenten des Host-Software-Backends sowie die Anbindung an die Solver und die wxwidgetgui beinhaltet. Alle Komponenten des Host-Software-Backends werden unter dem Begriff FEMCore zusammengefasst. Als Darstellungsform wird die Unified Modeling Language (Vereinheitlichte Modellierungssprache), kurz UML, verwendet, aus der das Komponentendiagramm gewählt wird. Das Komponentendiagramm (engl. component diagram) stellt verschiedene Bestandteile eines Systems als Komponenten dar. Es zeigt die Komponenten, wie sie zur Laufzeit organisiert sind, und die sich daraus ergebenden Abhängigkeiten (weitere Informationen: [RUQU2012, S. 216ff]). Aus dem Komponentendiagramm werden die beiden Objekte Komponente und Schnittstelle verwendet. Bild 3.5: Softwarearchitektur Wie Bild 3.5 zeigt, ist die aktuelle GUI (xwwidgetgui) an die Programmteile Gitterverwaltung und Simulationssteuerung angebunden. Exakt auf diese beiden Programmteile benötigt auch die WebGUI Zugriff. Da es keine Möglichkeit gibt, direkt aus dem Browser 32

35 via JavaScript auf die C++-Bibliotheken zuzugreifen, muss eine Lösung für dieses Problem gefunden werden. Zuerst wird eine Schnittstelle definiert, die den Informationsaustausch zwischen WebGUI und Gitterverwaltung bzw. Simulationssteuerung möglich macht. Diese Schnittstelle heißt FEMInterface und ist in C++ geschrieben. Sie erfüllt die folgenden Aufgaben: Bereitstellen eines WebSocket Servers, um die Kommunikation zwischen (Web)Client und FEMInterface (Server) zu ermöglichen. Anbinden des FEMCore, um eine Kommunikation von dem FEMInterface mit Gitterverwaltung bzw. Simulationssteuerung zu ermöglichen. Diese beiden Funktionen des FEMInterface machen es möglich, dass ein WebSocket-Client sich mit dem Server verbinden und durch dieses sowohl die Gitterverwaltung als auch die Simulationssteuerung ansprechen kann. Bild 3.6: Softwarearchitektur (Neu) Das Format für die Kommunikation sollte möglichst einfach und leicht verständlich gehalten werden. Daher werden im Client Nachrichtenobjekte generiert und diese vor der 33

36 Übertragung mit JSON serialisiert. Auf der Serverseite werden die Nachrichten dann deserialisiert und anschließend verarbeitet. Nachrichten zurück an den Client werden auch wieder im JSON-Format übertragen, so dass diese vom Client wieder deserialisiert werden können. Da bei der Serialisierung von Objekten in JSON ein relativ großer Overhead entsteht, werden große Dateien (nur relevant für Gitterdaten) in einem Rohdatenformat (RAW-Format) übertragen. Weitere Informationen zu den Datenformaten und dem Overhead können in Kapitel auf Seite 40 nachgelesen werden. Das Bild 3.6 auf Seite 33 zeigt die Architektur, nachdem die WebGUI mit angebunden wurde. 34

37 4 Technische Umsetzung Die Umsetzung der Software- und Systemarchitektur aus Kapitel 3 wird in diesem Kapitel thematisiert. Dabei wird zuerst vertieft auf die Technologie WebGL (Kapitel 4.1) eingegangen. Anschließend werden die Visualisierung von 3D-Daten (Kapitel 4.2), die Umsetzung der sonstigen GUI-Elemente (Kapitel 4.3) und zuletzt die möglichen Techniken zur Verbesserung der Datenübertragung (Kapitel 4.4) vorgestellt. 4.1 WebGL Detailliertere Technologiebetrachung Hier wird die Technologie WebGL tiefergehend betrachtet. Dabei wird der Unterschied zu OpenGL und die Interaktion mit JavaScript näher erläutert Gemeinsamkeiten und Unterschiede zu OpenGL Wie bereits in Kapitel auf Seite 11 erwähnt, basiert WebGL auf der Spezifikation von OpenGL ES 2.0 und behält dabei deren Semantik. Allerdings gibt es einige signifikante Unterschiede im Verhalten zwischen OpenGL ES 2.0 (WebGL) und der OpenGL API auf Desktop-Systemen, welche hier jedoch nicht weiter thematisiert werden, da sie sich nicht auf die Implementierung der WebGUI des SimCloud Projekts auswirken. Weitere Informationen und Codebeispiele können in der Quelle nachgeschaut werden. [KHRO2012] Interaktion mit JavaSkript Der Browser implementiert WebGL, indem er eine WebGL Schnittstelle für JavaScript anbietet, welche die Implementierung der OpenGL-ES-Spezifikation ist. WebGL wird in Java- Script ausschließlich durch die WebGL-JavaScript-Schnittstelle angesprochen. Der Grafiktreiber unterstützt die Implementierung von OpenGL ES und führt den Code aus. Wird jetzt WebGL durch JavaScript angesprochen, so übersetzt die Schnittstelle die Befehle und leitet diese an die Grafikkarte weiter, wo sie ausgeführt werden. (vgl. [PARI2012, S. 2f] und [SINI2011]) 35

38 4.2 3D Visualisierung der Simulationsdaten Die verschiedenen Schritte, die unternommen werden müssen, um die WebGUI basierend auf den Anforderungen aus Kapitel 3 umzusetzen, werden in diesem Kapitel erläutert. Die verwendeten Bibliotheken sind Thema im folgenden Kapitel Mithilfe dieser Bibliotheken wird der FEMCore mit der WebGUI über das FEMInterface verbunden. Als Übertragungsformat wird dabei JSON verwendet, welches im Kapitel definiert wird. Dies führt zu einer Herausforderung, da aufgrund der großen Menge an Overhead bei JSON ein weiteres Übertragungsformat für besonders große Dateien (Gitter-Dateien) benötigt wird, welches in Kapitel thematisiert wird. Mit der Erklärung der Implementierung des WebGL-Teils wird in Kapitel begonnen. Anschließend wird ein Vergleich zwischen reinem WebGL mit der Bibliothek Three.js aufgestellt. Basierend auf den Anforderungen an das Auswählen und Ausblenden von Elementen aus Kapitel 3 wird im Kapitel vorgestellt, wie Transparenz für einzelne Punkte in Three.js möglich ist. Basierend auf diesen Erkenntnissen wird in Kapitel das Auswählen von Elementen und in Kapitel das Ausblenden von Elementen vorgestellt. Abschließend werden noch in Kapitel die verschiedenen Möglichkeiten zur Umsetzung einer Legende erklärt Verwendete Bibliotheken Der erste Schritt der Umsetzung ist herauszufinden, welche Bibliotheken für das Projekt verwendet werden können. Die Bibliotheken leiten sich dabei aus der Software- und Systemarchitektur, welche in Kapitel 3.2 auf Seite 32 behandelt wurde, ab. Da sich die Implementierung für die folgenden Komponenten nach einer kurzen Recherche als sehr aufwendig herausstellt, werden diese durch Externe ersetzt. WebSocket-Server JSON-(De)Serialisierer Die Serialisierung eines Objekts ist ein Vorgang, bei dem der Zustand eines Objekts in einen String umgewandelt wird, aus dem es später wiederhergestellt werden kann (vgl. [FLAN2012, S. 148]). Da es eine Vielzahl von WebSocket-Server Implementierungen zur Auswahl gibt (sowohl in C als auch in C++), wurde sich hier auf einige wesentliche beschränkt. Die Folgenden werden anschließend näher betrachtet: 36

39 libwebsockets C-Bibliothek mit ws(s) und http(s) Unterstützung websocketpp C++-Bibliothek mit ws(s) Unterstützung WebSocketServer C++-Bibliothek mit ws und ohne wss Unterstützung. Server wird in LUA-Skript geschrieben Durch das Fehlen der Unterstützung für wss (WebSocket Verbindungen über https) und dem Zwang den Server in LUA-Skript zu schreiben, fällt WebSocketServer direkt aus der Auswahl heraus. Da die anderen Komponenten des Projekts (FEMCore) bereits in C++ geschrieben sind, bietet es sich an auch für die Bibliotheken C++ zu verwenden, weil so eine Vermischung von Code zwischen C und C++ Code vermieden wird. Da libwebsockets eine C-Bibliothek ist, fällt diese somit auch heraus. Für das Projekt wird also die Bibliothek WebSocket++ gewählt. Auch JSON-(De)Serialisierer gibt es in großer Zahl, wie eine kurze Recherche zeigt. Wie zuvor wird sich auch hier auf einige wenige, vielversprechende Implementierungen für einen ersten Vergleich konzentriert: JSON Spirit Generator-Implemented libjson JsonCpp Alle drei Bibliotheken erfüllen die Anforderungen für das Projekt. Es wird sich hier deshalb bei der Auswahl darauf beschränkt, die Bibliothek zu verwenden, bei der die Bedienung am intuitivsten erscheint. Sowohl JSON Spirit als auch JsonCpp sind, basierend auf den Beispielen, nicht einfach verständlich. Die Beispiele können auf den Internetseiten der Bibliotheken eingesehen werden. Ausschließlich bei libjson sind die Beispiele nur nach dem Download der Zip-Datei von der Internetseite einsehbar. Ein erster Blick auf die Beispiele von libjson hingegen lässt sofort darauf schließen, wie die Funktionen zu nutzen sind. Die Auswahl fällt daher auf libjson. 37

40 Nachdem die Auswahl der Bibliotheken getroffen ist, wird damit begonnen den Kommunikationskanal zwischen Client und Server (FEMInterface) zu implementieren. Auf der Serverseite kommt dafür WebSocket++ zum Einsatz, während im Client hierfür die Web- Socket API des Browsers verwendet wird. Die grundlegende Server-Implementierung besteht aus der Funktion main() und einer Funktion on message() für die ankommenden Nachrichten (Siehe: Listing 4.1). Listing 4.1: Rudimentäre Websocket Server Implementierung 1 v o i d on message ( s e r v e r s, websocketpp : : c o n n e c t i o n h d l hdl, 2 m e s s a g e p t r msg ) { 3 // I n h a l t der N a c h r i c h t a b f r a g e n 4 std : : s t r i n g message = msg >g e t p a y l o a d ( ) ; 5 // N a c h r i c h t z u r ü ck an den C l i e n t senden 6 s >send ( hdl, message, websocketpp : : frame : : opcode : : TEXT ) ; 7 } 8 i n t main ( ) { 9 // S e r v e r Endpunkt e r s t e l l e n 10 s e r v e r f e m s e r v e r ; 11 t r y { 12 // Logging a k t i v i e r e n 13 f e m s e r v e r. s e t a c c e s s c h a n n e l s ( websocketpp : : log : : a l e v e l : : a l l ) ; 14 f e m s e r v e r. c l e a r a c c e s s c h a n n e l s ( 15 websocketpp : : log : : a l e v e l : : f r a m e p a y l o a d ) ; // ASIO i n i t i a l i s i e r e n 18 f e m s e r v e r. i n i t a s i o ( ) ; // Nachrichten Handler r e g i s t r i e r e n 21 f e m s e r v e r. s e t m e s s a g e h a n d l e r ( 22 bind (&on message, &f e m s e r v e r, : : 1, : : 2 ) ) ; // Auf Port 9002 hö r en 25 f e m s e r v e r. l i s t e n ( ) ; // Beginnen Verbindungen zu a k z e p t i e r e n 28 f e m s e r v e r. s t a r t a c c e p t ( ) ; 29 38

41 30 // S e r v e r s t a r t e n 31 f e m s e r v e r. run ( ) ; 32 } catch ( c o n s t std : : e x c e p t i o n & e ) { 33 std : : cout << e. what ( ) << std : : e n d l ; 34 } catch ( websocketpp : : l i b : : e r r o r c o d e & e ) { 35 std : : cout << e. message ( ) << std : : e n d l ; 36 } catch (... ) { 37 std : : cout << o t h e r e x c e p t i o n << std : : e n d l ; 38 } 39 } Im Client wird dafür ein WebSocket-Objekt generiert, welches das Gegenstück zum Server darstellt. Das Objekt connection wird global deklariert, sodass alle Funktionen darauf Zugriff haben. In der Funktion initwebsocket() wird das Objekt dann initialisiert. Anschließend werden die benötigten Events (onopen, onerror und onmessage) angebunden. Über das Objekt connection wird die komplette Kommunikation mit dem Server abgewickelt (Siehe: Listing 4.2). Listing 4.2: Rudimentäre Websocket Client Implementierung 1 v a r c o n n e c t i o n = n u l l ; 2 function i nitwebsocket ( ) 3 { 4 c o n n e c t i o n = new WebSocket ( ws : / / : / ) ; 5 // Nachdem d i e Verbindung ge ö f f n e t i s t : Daten senden 6 c o n n e c t i o n. onopen = function ( e ) { 7 c o n n e c t i o n. send ( H e l l o S e r v e r ) ; 8 } ; 9 10 // F e h l e r l o g g e n 11 c o n n e c t i o n. o n e r r o r = function ( e r r o r ) { 12 v a r message = F a i l e d to connect to : + e r r o r. t a r g e t. u r l ; 13 c o n s o l e. log ( message ) ; 14 } ; // Nachrichgen l o g g e n 17 c o n n e c t i o n. onmessage = function ( e ) { 18 c o n s o l e. log ( e. data ) ; 39

42 19 } ; 20 } Aus Gründen der Übersichtlichkeit werden hier nur Code-Ausschnitte angezeigt. Mit der Kombination von Listing 4.1 und 4.2 ist es möglich, Nachrichten zwischen Client und Server auszutauschen. Wie bereits in Kapitel auf Seite 19 erwähnt, handelt es sich dabei um eine bidirektionale Verbindung zwischen Client und Server Anbinden des Backends Um die Verbindung zwischen Web-Client und dem Host-Software-Backend (FEMCore) abzuschließen, muss der FEMCore an das FEMInterface angebunden werden. Beide werden in C++ entwickelt, weshalb die Anbindung kein größeres Problem darstellt. Es muss lediglich dem FEMInterface-Projekt das FEMCore-Projekt als Referenz hinzugefügt werden, und anschließend kann auf die gewünschten Funktionen zugegriffen werden. Die Formulierung Projekt wird hier verwendet als Projekt in einer Entwicklungsumgebung (IDE) wie in diesem Fall Eclipse. Nachdem der Kommunikationskanal erfolgreich umgesetzt ist, kann damit begonnen werden das Datenformat zu entwerfen und anschließend zu implementieren Das Übertragunsformat In der ersten Version sind sämtliche Nachrichten im JSON-Format. Alle Objekte werden über einen Typ unterschieden und haben unterschiedlich viele weitere Parameter. Die Parameter für jeden Typ werden in Tabelle 4.1 auf Seite 41 aufgelistet. Eine Beispiel-Nachricht an den Server vom Typ setproblem sieht wie folgt aus: 1 // Nachrichten Objekt d e f i n i e r e n 2 v a r message = { } ; 3 // Parameter z u w e i s e n 4 message. typ = s e t p r o b l e m ; 5 message. kx = x ˆ 2 ; 6 message. ky = y ˆ 2 ; 7 message. kz = z ˆ 2 ; 8 message. f = xˆ2+yˆ2+z ; 9 // Objekt i n JSON S t r i n g s e r i a l i s i e r e n 10 v a r s t r i n g M e s s a g e = JSON. s t r i n g i f y ( message ) ; 40

43 Tabelle 4.1: Parameter der JSON-Objekte Typ Paramter Beschreibung grid Keine Parameter solution Keine Parameter materials Keine Parameter setting setting Name der Einstellung, value Wert der Einstellung setboundary facetid Element-ID neumann Funktions-String für: Neumann dirichlet Funktions-String für: Dirichlet robin1 Funktions-String für: Robin1 rbin2 Funktions-String für: Robin2 robin3 Funktions-String für: Robin3 setproblem r Funktions-String für: r kx Funktions-String für: k x ky Funktions-String für: k y kz Funktions-String für: k z f Funktions-String für: f setmaterial facetid Element-ID material Material dimension Dimension validatefunction function Funktions-String id ID für die Identification im Client 11 // { typ : s e t p r o b l e m, kx : x ˆ2, ky : y ˆ2, kz : z ˆ2, 12 // f : xˆ2+yˆ2+z } Der Server antwortet auf alle Nachrichten (außer dem Typ grid und solution) mit der gleichen Nachricht, es werden allerdings zwei zusätzliche Parameter angefügt. Valid und error message geben dem Client Informationen darüber, ob sein Befehl erfolgreich auf dem Server ausgeführt wurde oder nicht. Für die Nachrichtentypen grid und solution antwortet der Server mit einem Array aus Dreiecken. Ein Array ist eine geordnete Sammlung von Werten. Die einzelnen Werte bezeichnet man als Elemente. Jedes Element hat eine numerische Position im Array, die als Index bezeichnet wird. (vgl. [FLAN2012, S. 151]). Jedes Dreieck enthält wiederum Informationen zu den drei zugehörigen Punkten. Nachdem das Datenformat fertig spezifiziert ist, werden einige Tests durchgeführt, um die Leistungsfähigkeit des Formates zu überprüfen. Für diese Tests werden Testdateien generiert, die in Tabelle 4.2 aufgelistet sind. Für 167 k und 1,3 m Elemente können keine Werte festgestellt werden, da das Backend diese Dateien sehr langsam einliest und die 41

44 Konvertierung zu JSON-Objekten ebenso sehr zeitaufwendig ist. Die Tests werden jeweils nach etwas über zehn Minuten abgebrochen (Tabelle 4.2 Optimierung: Ohne). Eine erste Optimierung der Größe ist, von der write formated-funktion auf die write-funktion der Bibliothek libjson zu wechseln. Der Unterschied besteht darin, dass die erste Funktion den JSON-String formatiert und die zweite den String am Stück schreibt (Siehe Listing 4.3). Listing 4.3: Vergleich write und write formated 1 v a r t e s t = { 2 S t r i n g Node : S t r i n g Value, 3 I n t e g e r Node : 42, 4 F l o a t i n g Point Node : , 5 Boolean Node : t r u e 6 } 7 // Ausgabe mit w r i t e f o r m a t e d ( ) 8 { 9 S t r i n g Node : S t r i n g Value, 10 I n t e g e r Node : 42, 11 F l o a t i n g Point Node : , 12 Boolean Node : t r u e 13 } 14 // Ausgabe mit w r i t e ( ) 15 // Zeilenumbruch i s t nur f ü r d i e U e b e r s i c h t l i c h k e i t 16 { S t r i n g Node : S t r i n g Value, I n t e g e r Node : 42, 17 F l o a t i n g Point Node : , Boolean Node : t r u e } Weiterhin werden alle Beschriftungen für die Werte der Punkte entfernt, da diese nur der Lesbarkeit dienlich sind (Siehe Listing 4.4). Listing 4.4: Vergleich mit und ohne Beschriftung 1 v a r punktvorher = { 2 x : 42, 3 y : 43, 4 z : 44, 5 i d : 31, 6 r : 165, 7 g : 165, 8 b : 165, 9 a : 0, 42

45 10 v : } v a r punktnachher = [ 14 42, 15 43, 16 44, 17 31, , , , 21 0, ] Durch die beiden Änderungen aus Listing 4.3 und 4.4 wird die Größe um bis zu 55% reduziert (Tabelle 4.2 Optimierung: A). Es wird allerdings weiterhin versucht die Dateien zu verkleinern, da sie noch immer recht groß sind. Eine weitere Optimierung der Größe und gleichzeitiges Beibehalten des JSON-Formates ist nicht möglich. Obwohl alle überflüssigen Leerzeichen und Bezeichner entfernt sind, reichen die 12 GB Arbeitsspeicher des Testsystems bei Tests nicht aus, um die Datei mit 1,3 Millionen Elementen zu JSON zu konvertieren. Diese beiden Punkte führen dazu, dass ein anderer Ansatz verfolgt wird. Dieser Ansatz ist das RAW-Format, welches im nächsten Kapitel thematisiert wird RAW-Format Zu Beginn wird ein Format definiert, das grundlegend einen trennzeichenseparierten String darstellt und als RAW-Format bezeichnet wird. Das RAW-Format wird für die Übertragung von großen Datenmengen (nur relevant für Gitterdaten) verwendet. Hier liegt der Fokus auf der kompakten Übertragung der Daten und nicht wie bei JSON auf einem gut lesbaren bzw. (de)serialisierbaren Format. Für alle anderen Nachrichten wird weiterhin JSON verwendet. Bild 4.1: Aufbau RAW Objekt 43

46 Der Grundgedanke des RAW-Formates ist es, so wenig Speicherplatz für die Trennzeichen der Werte zu verwenden wie irgendwie möglich. Ein erster Entwurf ist in Bild 4.1 zu sehen. Das RAW-Format ist eine trennzeichenseparierte Zeichenkette und beginnt mit der Zeichenkette RAW (Bild 4.1 auf Seite 43). Es wird durch die verschiedenen Trennzeichen in drei Ebenen unterteilt. trennt Ebenen null und eins, Ebenen eins und zwei und Ebenen zwei und drei. Auf Ebene null definiert der erste String (nach RAW ) den Typ des Objekts und enthält weitere Informationen zum Objekt (S). Anschließend folgen dann die Dreiecke des Gitters (D 1 D n ). Ebene eins wird ausschließlich für die Dreiecke verwendet und trennt die einzelnen Punkte der Dreiecke voneinander (P 1, P 2, P 3 ). In Ebene zwei werden die Werte für die Punkte (X-, Y-, Z-Koordinate, Farbwert-Rot, -Grün, -Blau, Wert für die Transparenz und Wert der Lösung) angegeben, ebenfalls aber auch die Informationen zum Typ (siehe erster String). Die Größe der Antworten für die verschieden Dateien sind in Tabelle 4.2 dargestellt (Optimierung: B). Tabelle 4.2: Größe der Antworten der verschieden Dateien Optimierung [MB] Dateiname Anzahl Elemente Ohne A (45%) B (38%) C (28%) D (27%) shaft.vol ,8 1,7 1,44 1,01 1,01 shaft 20k.vol ,7 13,1 11,11 8,27 8,08 shaft 167k.vol ,1 103,1 88,01 64,51 63,11 shaft 1.3m.vol ,6 831,8 704,99 512,85 501,88 Die Werte in kusiv sind basierend auf den anderen Werten berechnet. Die % Zahl im Header bezieht sich jeweils auf die Optimierungsstufe Ohne Der nächste Schritt besteht darin die Genauigkeit der zu übertragenden Werte zu reduzieren. Hierfür wird von boost::lexical cast<std::string>() auf std::to string() gewechselt (siehe: Tabelle 4.2 Optimierung: C). lexical cast<>() ist eine Funktion aus der C++ Bibliothek Boost (siehe: [BOOS2014]). std::to:string ist in der Header-Datei string definiert. Beide Funktionen konvertieren eine Zahl in eine Zeichenkette (String). lexical cast verwendet dabei eine höhere Genauigkeit als std::to string. Um zu überprüfen, ob dieser Schritt möglich ist wird zunächst ein 3D-Modell mit der höherer Genauigkeit geladen (lexica cast) und anschließend mit eines der niedrigeren Genauigkeit (std::to string). Diese beiden Ansichten werden danach auf optische Unterschiede überprüft. Bei dieser Überprüfung stellt sich heraus, dass es keinen Unterschied in der Darstellung gibt, der auf die veränderte Genauigkeit zurückzuführen ist. Mit dem Ziel die Größe noch weiter zu verringern, werden die Trennzeichen wie folgt ersetzt: 44

47 < > Dies führt zur letzten Optimierungsstufe (siehe: Tabelle 4.2 auf Seite 44 Optimierung: D). Es ist anzumerken, dass es auch in der letzten Optimierungsstufe nicht möglich ist, das Gitter mit 1,3 Millionen Elemente zu übertragen. Bereits nach 50% der Daten stürzt der Browser bzw. das Browser-Tab ab. Getestet wird in Google Chrome (Version dev-m ). Mit dieser letzten Optimierungsstufe ist das Entwerfen, Optimieren und Implementieren des Datenformats abgeschlossen, und es kann damit begonnen werden die Visualisierung der Daten in WebGL umzusetzen. Weitere theoretische Möglichkeiten zur Optimierung der Übertragung sind in Kapitel 4.4 auf Seite 76 zu finden Perspektivische und Orthographische Ansichten Bevor die Implementierung von WebGL durchgeführt werden kann, muss erst einmal die Art der Kameraansicht festgelegt werden. Es stehen die orthographische und perspektivische Ansichten zur Auswahl. Bei der orthographischen Ansicht verändert sich die Größe der Objekte nicht, wenn diese weiter entfernt von der Kamera sind. Diese Ansicht ist für den Menschen eher ungewohnt. Bei der perspektivischen Ansicht hingegen werden Elemente, die weiter von der Kamera entfernt sind, kleiner dargestellt. An diese Ansicht ist das menschliche Auge gewöhnt. Bild 4.2 zeigt einen Vergleich der beiden Ansichten. Bild 4.2: Perspektivische und Orthographische Ansichten Quelle: [NH3D2011] 45

48 4.2.6 Reines WebGL vs Three.js Die erste Version der Umsetzung der Darstellung des 3D-Modells wird in reinem WebGL implementiert. Bei dieser Art der Implementierung stehen nur die Standardfunktionen der WebGL API zur Verfügung, während alle anderen Funktionen selbst implementiert werden müssen. Bei Three.js hingegen gibt es für die meisten Anwendungsfälle bereits eine Funktion oder Helfer-Klasse. Um den Unterschied zwischen der Implementierung des Projekts in reinem WebGL im Vergleich zu der Implementierung in Three.js etwas klarer zu machen, wird hier ein Beispiel in beiden Varianten implementiert. Das Beispiel ist ein einfaches weißes Rechteck auf schwarzem Hintergrund mit der Höhe und Breite eins. Begonnen wird mit der Implementierung in reinem WebGL. Zuerst muss die Zeichen Umgebung von einem HTML5 Canvas Element abgefragt werden. In dieser Umgebung wird dann der WebGL-Inhalt gerendert. Beim Vorgang des renderns werden die vom Entwickler generierten 3D-Objekte gezeichnet und für den Benutzer dargestellt. Listing 4.5 zeigt, wie es möglich ist die Zeichen-Umgebung in JavaScript abzufragen. Listing 4.5: WebGL-Kontext abfragen [PARI2012, S. 10] 1 function initwebgl ( canvas ) { 2 v a r g l ; 3 t r y 4 { 5 g l = canvas. g e t C o n t e x t ( e x p e r i m e n t a l webgl ) ; 6 } 7 catch ( e ) 8 { 9 v a r msg = F e h l e r beim a b f r a g e n der WebGL Umgebung! : 10 + e. t o S t r i n g ( ) ; 11 throw E r r o r ( msg ) ; 12 } 13 return g l ; 14 } Nachdem die Zeichen-Umgebung abgefragt ist, kann der Viewport initialisiert werden. Dieser ist der Bereich des Canvas, in dem gezeichnet werden soll. Um den Viewport zu setzen, muss nur die viewport()-methode aufgerufen werden (Siehe: Listing 4.6 auf Seite 47). 46

49 Listing 4.6: Viewport initialisieren [PARI2012, S. 11] 1 function i n i t V i e w p o r t ( gl, canvas ) { 2 g l. v i e w p o r t ( 0, 0, canvas. width, canvas. h e i g h t ) ; 3 } In diesem Beispiel wird der Viewport auf die komplette Höhe und Breite des Canvas gesetzt. Nach der Initialisierung des Viewports ist die Umgebung bereit zum Zeichnen. Das Zeichnen in WebGL wird durch einfache grafische Primitive umgesetzt (weitere Informationen zu grafischen Primitiven siehe: [SCHA2009, S. 21ff]. Es gibt Dreiecke, Punkte und Linien. Die Position der Eckpunkte dieser Primitive werden in Datenarrays, genannt Buffer, abgelegt. Eine Funktion, um ein Quadrat mit der Breite und Höhe eins und dem Mittelpunkt im Nullpunkt zu zeichnen, ist in Listing 4.7 dargestellt. Listing 4.7: Buffer mit Eckpunkten für ein Quadrat befüllen [PARI2012, S. 12] 1 function c r e a t e S q u a r e ( g l ) { 2 v a r v e r t e x B u f f e r ; 3 v e r t e x B u f f e r = g l. c r e a t e B u f f e r ( ) ; 4 g l. b i n d B u f f e r ( g l. ARRAY BUFFER, v e r t e x B u f f e r ) ; 5 v a r v e r t s = [ , 0. 5, 0. 0, 7 0.5, 0. 5, 0. 0, , 0.5, 0. 0, 9 0.5, 0.5, ] ; 11 g l. b u f f e r D a t a ( g l. ARRAY BUFFER, new F l o a t 3 2 A r r a y ( v e r t s ), 12 g l. STATIC DRAW ) ; 13 v a r s q u a r e = { b u f f e r : v e r t e x B u f f e r, v e r t S i z e : 3, n V e r t s : 4, 14 p r i m t y p e : g l. TRIANGLE STRIP } ; 15 return s q u a r e ; 16 } Die Funktion gibt ein Objekt zurück, das alle relevanten Informationen über das Quadrat enthält: Buffer mit den Daten (buffer), Anzahl der Eckpunkte (nverts), Anzahl der Werte pro Punkt (vertsize) und die Art des Objekts (primtype). Bevor das Quadrat gezeichnet werden kann, müssen noch zwei wichtige Matrizen definiert werden. Als erstes die modelviewmatrix, welche die Position des Quadrates relativ zur Kamera festlegt. In diesem Beispiel ist das Quadrat -3,33 Einheiten in Z-Richtung verschoben. Die zweite ist 47

50 die projectionmatrix. Diese wird vom Shader benötigt, um die 3D- in 2D-Koordinaten zu konvertieren. Listing 4.8 zeigt diese beiden Matrizen. Listing 4.8: Initialisieren der Projection- und ModelView Matrix [PARI2012, S. 13] 1 function i n i t M a t r i c e s ( ) { 2 // Matrix f ü r das Quadrat t r a n s f o r m i e r e n v e r s c h i e b e n i n Z 3 // f ü r d i e Kamera 4 modelviewmatrix = new F l o a t 3 2 A r r a y ( 5 [ 1, 0, 0, 0, 6 0, 1, 0, 0, 7 0, 0, 1, 0, 8 0, 0, 3.33, 1 ] 9 ) ; // Die p r o j e c t i o n Matrix (45 d e g r e e f i e l d o f view ) 12 p r o j e c t i o n M a t r i x = new F l o a t 3 2 A r r a y ( 13 [ , 0, 0, 0, 14 0, , 0, 0, 15 0, 0, , 1, 16 0, 0, , 0 ] 17 ) ; 18 } Zuletzt müssen noch die Shader definiert werden. Shader sind kleine Programme, die in einer C-ähnlichen Sprache (OpenGL Shading Language (siehe: [KHRO2014b])) geschrieben sind und festlegen, wie die Pixel für ein Objekt gezeichnet werden. Ein Shader besteht typischerweise aus zwei Teilen: dem Vertex-Shader und dem Fragment- bzw. Pixel- Shader. Der Vertex-Shader transformiert die Eckpunkt-Koordinaten in 2D-Bildschirm- Koordinaten. Der Fragment-Shader hingegen ist zuständig für die Farbe der einzelnen Pixel der transformierten Eckpunkte. Dabei werden Aspekte wie Farbe, Textur, Licht und Material mit einbezogen. Der Vertex-Shader in diesem Beispiel kombiniert nur die model- ViewMatrix und projectionmatrix, um die finale Position für jeden Eckpunkt zu generieren. Im Fragment-Shader wird jedem Punkt die feste Farbe Weiß zugewiesen (Listing 4.9 auf Seite 49). 48

51 Listing 4.9: Vertex- und Fragment-Shader [PARI2012, S. 14] 1 v a r v e r t e x S h a d e r S o u r c e = 2 a t t r i b u t e vec3 v e r t e x P o s ; \ n + 3 uniform mat4 modelviewmatrix ; \ n + 4 uniform mat4 p r o j e c t i o n M a t r i x ; \ n + 5 v o i d main ( v o i d ) { \n + 6 // Return the t r a n f o r m e d and p r o j e c t e d v e r t e x v a l u e \n + 7 g l P o s i t i o n = r o j e c t i o n M a t r i x modelviewmatrix \n + 8 vec4 ( vertexpos, 1. 0 ) ; \ n + 9 }\n ; v a r fragmentshadersource = 12 v o i d maint ( v o i d ) {\n + 13 // Return the p i x e l c o l o r : alway output white \n + 14 g l F r a g C o l o r = vec4 ( 1. 0, 1. 0, 1. 0, 1. 0 ) ; \ n + 15 }\n ; Nachdem die Shader erstellt sind, kann mit dem Zeichnen begonnen werden, welches in der Funktion draw() implementiert ist (Listing 4.10). Zuerst wird das komplette Canvas geleert, indem es mit schwarzer Farbe gefüllt wird (clearcolor()). Anschließend wird der Buffer mit dem Quadrat angebunden (bindbuffer()), das Shader Programm geladen (useprogram()) und der Vertex-Shader mit den Matrizen verbunden (vertexattrib- Pointer() und uniformmatrix4fv()). Abschließend wird drawarrays() aufgerufen, um das Quadrat zu zeichnen. Das Ergebnis kann in Bild 4.3 auf Seite 50 eingesehen werden (vgl. [PARI2012, S. 9ff]). Listing 4.10: Das Quadrat zeichnen [PARI2012, S. 14f] 1 function draw ( gl, o b j ) { 2 // H i n t e r g r u n d mit d er Farbe Wei ß f ü l l e n 3 g l. c l e a r C o l o r ( 0. 0, 0. 0, 0. 0, 1. 0 ) ; 4 g l. c l e a r ( g l. COLOR BUFFER BIT ) ; 5 6 // Zeichnen im Vertex B u f f e r a k t i v i e r e n 7 g l. b i n d B u f f e r ( g l. ARRAY BUFFER, o b j. b u f f e r ) ; 8 9 // Shader l a d e n 10 g l. useprogramm ( shaderprogramm ) ; 49

52 11 12 // E i n s t e l l u n g e n der Shader mit der 13 // p r o j e c t i o n / model M a r t r i c e s v e r b i n d e n 14 g l. v e r t e x A t t r i b P o i n t e r ( s h a d e r V e r t e x P o s i t i o n A t t r i b u t e, 15 o b j. v e r t S i z e, g l. FLOAT, f a l s e, 0, 0 ) ; 16 g l. u n i f o r m M a t r i x 4 f v ( s h a d e r P r o j e c t i o n M a t r i x U n i f o r m, f a l s e, 17 p r o j e c t i o n M a t r i x ) ; 18 g l. u n i f o r m M a t r i x 4 f v ( shadermodelviewmatrixuniform, f a l s e, 19 modelviewmatrix ) ; // Objekt z e i c h n e n 22 g l. drawarrays ( o b j. primtype, 0, o b j. n V e r t s ) ; 23 } Bild 4.3: Quadrat WebGL / Three.js Im Vergleich dazu folgt die Implementierung für das gleiche Quadrat in Three.js (Listing 4.11 auf Seite 51). Alle Objekte aus Three.js die für die Umsetzung relevant sind, werden im Folgenden erklärt. Der Raum, in dem alles platziert wird, heißt Scene und wird durch ein THREE.Scene Objekt umgesetzt (siehe: [CABE2014a, Kapitel Scene]). Um in diese Scene hineinschauen zu können, wird eine Kamera (THREE.PerspectiveCamera oder THREE.OrthographicCamera) benötigt (siehe: [CABE2014a, Kapitel PerspectiveCamera und OrthographicCamera]). Die Gitterstrukturen werden durch eine THREE.Geometry abgebildet, die Oberfläche für diese Gitterstrukturen (Farben der Punkte, Transparenz) durch ein THREE.Material (siehe: [CABE2014a, Kapitel Geometry und Material]). Von THREE.- 50

53 Geometry und THREE.Material gibt es noch diverse Unterklassen. Diese werden, falls sie Verwendung finden, später erklärt (für THREE.MeshBasicMaterial und THREE.Shader- Material siehe Kapitel auf Seite 53). Um das 3D-Objekt in der Scene darstellen zu können, wird aus diesen beiden Komponenten ein THREE.Mesh generiert, welches dann das fertige 3D-Objekt darstellt und der Scene hinzugefügt werden kann (siehe: [CABE2014a, Kapitel Mesh]). Für die Beleuchtung bzw. die Lichtquellen wird ein THREE.Light verwendet (siehe: [CABE2014a, Kapitel Light]). In diesem Projekt kommt ausschließlich ein THREE.PointLight zum Einsatz (siehe: [CABE2014a, Kapitel PointLight]). Um die komplette Scene mit der Kamera im Browser darstellen zu können, muss diese noch gerendert werden. Dafür wird ein THREE.WebGLRenderer gebraucht (siehe: [CABE2014a, Kapitel WebGLRenderer]). Listing 4.11: Ein Quadrat zeichnen mit Three.js [PARI2012, S. 20f] 1 <!DOCTYPE html> 2 <html> 3 <head> 4 <t i t l e >A Simple Three. j s Page</ t i t l e > 5 < s c r i p t s r c =../ l i b s / Three. j s ></ s c r i p t > 6 <s c r i p t > 7 function onload ( ) { 8 // C o n t a i n e r d i v a b f r a g e n 9 v a r c o n t a i n e r = document. getelementbyid ( c o n t a i n e r ) ; // Three. j s Render e r s t e l l e n und dem d i v z u w e i s e n 12 v a r r e n d e r e r = new THREE. WebGLRenderer ( ) ; 13 r e n d e r e r. s e t S i z e ( c o n t a i n e r. o f f s e t W i d t h, 14 c o n t a i n e r. o f f s e t H e i g h t ) ; 15 c o n t a i n e r. appendchild ( r e n d e r e r. domelement ) ; // Three. j s Szene g e n e r i e r e n 18 v a r s c e n e = new THREE. Scene ( ) ; // Kamera g e n e r i e r e n und der Szene h i n z u f ü gen 21 v a r camera = new THREE. P e r s p e c t i v e C a m e r a ( 45, 22 c o n t a i l e r. o f f s e t W i d t h / c o n t a i n e r. o f f s e t H e i g h t, 23 1, ) ; 51

54 24 camera. p o s i t i o n. set ( 0, 0, ) ; 25 s c e n e. add ( camera ) ; // Rechteck e r s t e l l e n und der Sczene h i n z u f ü gen 28 v a r geometry = new THREE. PlaneGeometry ( 1, 1 ) ; 29 v a r mesh = new THREE. Mesh ( geometry, 30 new THREE. M e s h B a s i c M a t e r i a l ( ) ) ; 31 s c e n e. add (mesh ) ; // Rendern 34 r e n d e r e r. r e n d e r ( scene, camera ) ; 35 } 36 </ s c r i p t > 37 </head> 38 <body onload= onload (); > 39 <d i v i d = c o n t a i n e r s t y l e = width :500 px ; h e i g h t :500 px; ></ div > 40 </body> 41 </html> Auch hier kann das Ergebnis in Bild 4.3 auf Seite 50 angesehen werden. Zunächst wird die Anzahl der benötigten Code-Zeilen verglichen. In reinem WebGL werden 88 Zeilen benötigt, wobei noch der komplette HTML-Teil der Seite fehlt. Vergleicht man das mit dem Three.js Code, der nur 27 Zeilen (39 Zeilen mit HTML-Anteil) benötigt, stellt man fest, dass mit Three.js gerade mal ein Drittel des Codes benötigt wird. Außerdem sieht der Code deutlich übersichtlicher und gepflegter aus. Das führt dazu, dass die Wartbarkeit des Codes deutlich zunimmt, ebenso wird es einfacher, mit mehreren Entwicklern an einem Projekt zu arbeiten. Während bei reinem WebGL noch die Matrizen aufgestellt und miteinander multipliziert werden mussten, passiert das bei Three.js alles intern und der Entwickler muss sich darum nicht kümmern. Das führt auch dazu, dass Bibliotheken wie glmatrix (siehe: [JONE2014]) nicht extra eingebunden werden müssen. glmatrix ist eine JavaScript Bibliothek für die mathematischen Operationen mit Matrizen und Vektoren, die auf Geschwindigkeit optimiert ist. Weitergehend muss keine eigene Funktion drawscene() generiert werden, in der alle Operationen an der Scene (Rotation, Translation) durchgeführt werden müssen. Wiederum führt dies dazu, dass der Entwickler viel weniger Wissen im Bereich der 3D-Mathematik haben muss, wenn er Three.js verwendet als bei der Nutzung von WebGL. Ein weiterer 52

55 wichtiger Aspekt ist, dass in Three.js das Selektieren von Elementen (Picking) bereits unterstützt wird und es in WebGL nur mit einem großen (Arbeits-) Aufwand möglich ist, diese Funktion selbst zu implementieren. Weitere Informationen zum Selektieren von Elementen sind in Kapitel auf Seite 59 zu finden. Auch hier wäre wieder ein sehr gutes Verständnis im Bereich der 3D-Mathematik erforderlich (vgl. [GREG2012]). Zusammengefasst hat es nur Vorteile Three.js anstelle von WebGL zu verwenden MeshBasicMaterial, ShaderMaterial und Transparenz Für die Darstellung der Dreiecke des 3D-Objekts wird eine THREE.Geometry verwendet. Dieses Objekt beinhaltet alle relevanten Informationen für die Struktur eines 3D-Objekts. Würde man dieses Objekt visualisieren, wäre es das 3D-Objekt als Gitter-Struktur. Jede Geometry beinhaltet eine id zur Identifikation, einen Array vertices für die Punkte, ein Array colors für die Farben pro Punkt und ein Array faces für die Dreiecke. Es gibt noch diverse andere Eigenschaften, diese sind jedoch für die Umsetzung nicht relevant. Eine komplette Liste der Eigenschaften kann in der Quelle nachgelesen werden. Neben der THREE.Geometry wird noch ein THREE.Material benötigt. Mit dem Material wird die (Ober-) Fläche der Geometry und deren Eigenschaften beschrieben. Für die erste Version der Umsetzung wird ein THREE.MeshBasicMaterial gewählt (siehe: [CABE2014a, Kapitel MeshBasicMaterial]). Die relevante Eigenschaft dieses Materials ist vertexcolors. Mit dieser wird dem Material mitgeteilt, dass für die Farben der Dreiecke (faces) die Farben der Punkte (vertices) verwendet werden sollen. Der Wert dafür ist THREE.VertexColors. 1 v a r m a t e r i a l = new THREE. M e s h B a s i c M a t e r i a l ( 2 { v e r t e x C o l o r s : THREE. V e r t e x C o l o r s } 3 ) ; THREE.Geometry und THREE.MeshBasicMaterial sind eigenständige Objekte. Damit diese gezeichnet werden können, müssen sie in einem THREE.Mesh zusammengefasst und abschließend der Scene hinzugefügt werden. Ein triviales Beispiel ist im folgenden Listing zu sehen. Anstelle einer THREE.Geometry wird hier eine THREE.CubeGeometry verwendet, um das Beispiel möglichst einfach und kurz zu halten. Three.CubeGeometry(1, 1, 1) erstellt einen Würfel mit Kantenlänge eins. THREE.MeshBasicMaterial({ color: 0x00FF00 }) erstellt ein Material mit der Farbe Grün (0x00FF00). 1 v a r geometry = new THREE. CubeGeometry ( 1, 1, 1 ) ; 2 v a r m a t e r i a l = new THREE. M e s h B a s i c M a t e r i a l ( { c o l o r : 0x00FF00 } ) ; 3 v a r mesh = new THREE. Mesh ( geometry, m a t e r i a l ) ; 53

56 4 s c e n e. add ( mesh ) ; Das THREE.MeshBasicMaterial erfüllt soweit seinen Zweck. Es muss, basierend auf den Anforderungen, möglich sein Elemente transparent zu schalten. Zum Einen wird diese Funktionalität benötigt, um nur Lösungswerte in einem bestimmten Bereich anzuzeigen. Hier könnte es sein, dass bei einer beispielhaften Werteskala von 0 bis 42 nur die Werte von 37 bis 42 relevant sind. Weitergehend muss es auch möglich sein, Elemente auszublenden, die die Sicht auf andere Elemente versperren. Der Benutzer könnte sich für den Farbverlauf im Inneren des Modells interessieren und dieser ist nur schwer anzusehen, wenn alle Elemente vom Inneren zum Rand auch sichtbar sind. Leider unterstützt die Implementierung des Farb-Objekts THREE.Color nur die Werte Rot, Grün und Blau (RGB) und keinen zusätzlichen Wert für Transparenz/Alpha (RGBA) (siehe: [CABE2014a, Kapitel Color]). Das THREE.MeshBasicMaterial hat die Eigenschaften transparency und opacity. Wenn man die Eigenschaft transparency auf true (aktiviert) und opacity auf einen Wert zwischen 1,0 (komplett sichtbar) und 0,0 (komplett ausgeblendet) setzt, wird das Material transparent. Diese Möglichkeit, die Transparenz zu aktivieren, ist sehr einfach. Leider ist der Nachteil dieser Umsetzung, dass der opacity-wert für das komplette THREE.Mesh- BasicMaterial gilt. Es ist also nicht möglich, einzelne Dreiecke oder Punkte auf transparent zu schalten und den Rest unverändert zu lassen. Eine erste Lösung für dieses Problem ist, nicht das komplette 3D-Modell als ein THREE.- Mesh zu erzeugen sondern als N-teiliges THREE.Mesh, wobei N die Anzahl der Dreiecke des 3D-Modells ist. Der Vorteil hierbei liegt darin, dass man jetzt für jedes Dreieck den opacity-wert unabhängig von den anderen einstellen kann. Leider überwiegen auch hier die Nachteile. Es kann noch immer kein opacity-wert für jeden Punkt gesetzt werden (nur für jedes Dreieck). Weitergehend ist es ein großer Nachteil die Performance betreffend für jedes Dreieck ein eigenes THREE.Mesh zu generieren. Zum einen führt das bei größeren Modellen zu niedrigeren FPS-Werten (Bilder pro Sekunde) und zum anderen müssen Operationen wie Rotation, Translation oder Skalierung auf N und nicht mehr nur auf ein THREE.Mesh angewendet werden. Es muss eine andere Möglichkeit gefunden werden, um dieses Problem zu lösen. Das THREE.ShaderMaterial ist eine Lösung, die Transparenz für jeden Punkt und die Verwendung von nur einem THREE.Mesh zu ermöglichen (siehe: [CABE2014a, Kapitel ShaderMaterial]). Durch dessen Verwendung hat man die Möglichkeit, entweder weiter die Farben aus dem Array colors der THREE.Geomertry zu verwenden, oder aber die Farben über einen eigenen Shader zu steuern. Letzteres ermöglicht es, das gewünschte Ziel zu 54

57 erreichen. Hierfür müssen jedoch erst einmal die Shader (Vertex- und Fragment-Shader) definiert werden, die für das THREE.ShaderMaterial benötigt werden. Listing 4.12 und 4.13 zeigen jeweils einen sehr rudimentären Shader, der als Basis verwendet wird. Listing 4.12: Rudimentärer Vertex-Shader 1 < s c r i p t type= x s h a d e r /x v e r t e x i d = v e r t e x s h a d e r > 2 v o i d main ( ) 3 { 4 g l P o s i t i o n = p r o j e c t i o n M a t r i x modelviewmatrix 5 vec4 ( p o s i t i o n, 1. 0 ) ; 6 } 7 </ s c r i p t > Listing 4.13: Rudimentärer Fragment-Shader 1 < s c r i p t type= x s h a d e r /x fragment i d = f r a g m e n t s h a d e r > 2 v o i d main ( ) 3 { 4 // S e t t i n g Each P i x e l To Red 5 g l F r a g C o l o r = vec4 ( 1. 0, 0. 0, 0. 0, 1. 0 ) ; 6 } 7 </ s c r i p t > Diese beiden Shader haben noch keine besondere Funktion. Im Vertex-Shader wird die Postion für jedes Pixel bestimmt, indem die ModelViewProjectionMatrix (ModeViewMatrix ProjectionMatrix) mit dem Vertex (Position des Pixels vor der Transformierung) multipliziert wird. Im Fragment-Shader wird dann jedem Punkt die Farbe Rot zugewiesen. Diese beiden Shader werden anschließend modifiziert. Es werden dem Vertex-Shader (Listing 4.12) die Variablen customcolor und customopacity hinzugefügt. Der Typ vec3 ist ein Vektor der Länge drei und float eine Gleitkommazahl. Das zusätzliche Präfix attribute besagt, dass diese Werte von außen (z.b. aus JavaScript) dem Shader übergeben werden. Die Alternative zum attribute-präfix ist das uniform-präfix (findet hier keine Verwendung). Der Unterschied zu diesem ist, dass es nur einen Wert pro Shader gibt und bei attribute einen Wert für jeden Vertex (Punkt/Pixel). Zusätzlich werden die Variablen vcolor und vopacity definiert. Das Präfix varying bedeutet, dass sowohl der Vertex- als auch der Fragment-Shader Zugriff auf diese Variablen haben. Wie beim attribute- gibt es auch beim varying-präfix einen Wert für jeden Ver- 55

58 tex. In der Funktion main wird customcolor vcolor und custoopacity vopacity zugewiesen, damit die Werte von customcolor und custoopacity auch im Fragment-Shader zur Verfügung stehen. Der modifizierte Vertex-Shader ist in Listing 4.14 abgebildet. Listing 4.14: Modifizierter Vertex-Shader für das THREE.ShaderMaterial 1 < s c r i p t type= x s h a d e r /x v e r t e x i d = v e r t e x s h a d e r > 2 a t t r i b u t e vec3 customcolor ; 3 a t t r i b u t e f l o a t customopacity ; 4 5 v a r y i n g vec3 v C o l o r ; 6 v a r y i n g f l o a t vopacity ; 7 8 v o i d main ( ) { 9 v C o l o r = customcolor ; 10 vopacity = customopacity ; 11 g l P o s i t i o n = p r o j e c t i o n M a t r i x modelviewmatrix 12 vec4 ( p o s i t i o n, 1. 0 ) ; 13 } 14 </ s c r i p t > Auch dem Fragment-Shader (Listing 4.13 auf Seite 55) werden die Variablen vcolor und vopacity hinzugefügt. Diese werden verwendet, um die Farbe und Transparenz für jeden Punkt zu setzen. Die Farbe gl FragColor ist ein Vektor der Länge vier (vec4) und beinhaltet die drei Farbwerte (Rot, Grün und Blau) und den Transparenz- bzw. Alphawert. Der modifizierte Fragment-Shader ist in Listing 4.15 dargestellt. Listing 4.15: Modifizierter Fragment-Shader für das THREE.ShaderMaterial 1 < s c r i p t type= x s h a d e r /x fragment i d = f r a g m e n t s h a d e r > 2 v a r y i n g vec3 v C o l o r ; 3 v a r y i n g f l o a t vopacity ; 4 5 v o i d main ( ) { 6 g l F r a g C o l o r = vec4 ( vcolor, vopacity ) ; 7 } 8 </ s c r i p t > Nachdem die Shader fertiggestellt sind, müssen die attribute Variablen mit dem Java- Script-Code verknüpft werden. Dafür wird zunächst ein Objekt mit dem Namen attribu- 56

59 tes in JavaScript definiert und die benötigten Parameter zugewiesen (Listing 4.16). Type c steht für einen Farbwert (Array mit drei Werten) und f für eine Gleitkommazahl (float). Dem value wird jeweils ein leeres Array zugewiesen. 1 v a r a t t r i b u t e s = { Listing 4.16: Attribute Objekt 2 customcolor : { type : c, v a l u e : [ ] }, 3 customopacity : { type : f, v a l u e : [ ] } 4 } ; Unter der Verwendung der beiden Shader und des attributes-objektes kann nun das THREE.ShaderMaterial erstellt werden. Es werden noch einige zusätzliche Parameter gesetzt. blending wird auf THREE.NormalBlending gesetzt. Dieser Wert wird über Try n error ermittelt und ist der Werte, bei dem die Farben korrekt dargestellt wurden. depthtest (siehe: [KHRO2013b]) wurde mit true aktiviert. transparent: true aktiviert die Transparenz. side: THREE.DoubleSide gibt an, dass beide Seiten eines Dreiecks gezeichnet werden sollen. Falls dieser Wert nicht gesetzt ist, müssen alle Punkte des Dreiecks in der richtigen Reihenfolge hinzugefügt werden. Die Vorderseite eines Dreiecks wird dann berechnet, indem der Richtungsvektor basierend auf den Punkten des Dreiecks im Uhrzeigersinn bestimmt wird. linewidth: 2 setzt die Breite der Linien auf zwei. Das vollständige shadermaterial ist in Listing 4.17 abgebildet. Listing 4.17: Initialisierung ShaderMaterial 1 v a r s h a d e r M a t e r i a l = new THREE. S h a d e r M a t e r i a l ({ 2 a t t r i b u t e s : a t t r i b u t e s, 3 v e r t e x S h a d e r : 4 document. getelementbyid ( v e r t e x s h a d e r ). t e xtcontent, 5 fragmentshader : 6 document. getelementbyid ( f r a g m e n t s h a d e r ). t extcontent, 7 b l e n d i n g : THREE. NormalBlending, 8 depthtest : true, 9 t r a n s p a r e n t : true, 10 s i d e : THREE. DoubleSide, 11 l i n e w i d t h : 2 12 } ) ; Abschließend werden alle Komponenten zusammengeführt. Ein kurzes Beispiel für ein einziges Dreieck ist in Listing 4.18 auf Seite 58 dargestellt. 57

60 Listing 4.18: Ein einfaches Dreieck mit ShaderMaterial 1 // Objekt f ü r d i e Shader A t t r i b u t e e r s t e l l e n 2 v a r a t t r i b u t e s = { 3 customcolor : { type : c, v a l u e : [ ] }, 4 customopacity : { type : f, v a l u e : [ ] } 5 } ; 6 7 // Geometrie e r s t e l l e n 8 v a r geometry = new THREE. Geometry ( ) ; 9 // Punkt 1 mit der Farbe Grün und ohne Transparenz 10 geometry. v e r t i c e s. push ( new THREE. Vector3 ( 0. 0, 0. 0, 0. 0 ) ; 11 a t t r i b u t e s. customcolor. v a l u e [ 0 ] = 12 new THREE. C o l o r (THREE. ColorKeywords. green ) ; 13 a t t r i b u t e s. customopacity. v a l u e [ 0 ] = 1. 0 ; // Punkt 2 mit der Farbe Blau und 34% t r a n s p a r e n t 16 geometry. v e r t i c e s. push ( new THREE. Vector3 ( 1. 0, 2. 0, 0. 0 ) ; 17 a t t r i b u t e s. customcolor. v a l u e [ 1 ] = 18 new THREE. C o l o r (THREE. ColorKeywords. b l u e ) ; 19 a t t r i b u t e s. customopacity. v a l u e [ 1 ] = ; // Punkt 3 mit der Farbe Blau und 67% t r a n s p a r e n t 22 geometry. v e r t i c e s. push ( new THREE. Vector3 ( 2. 0, 0. 0, 0. 0 ) ; 23 a t t r i b u t e s. customcolor. v a l u e [ 2 ] = 24 new THREE. C o l o r (THREE. ColorKeywords. red ) ; 25 a t t r i b u t e s. customopacity. v a l u e [ 2 ] = ; // S h a d e r M a t e r i a l e r s t e l l e n 28 v a r s h a d e r M a t e r i a l = new THREE. S h a d e r M a t e r i a l ({ 29 a t t r i b u t e s : a t t r i b u t e s, 30 v e r t e x S h a d e r : 31 document. getelementbyid ( v e r t e x s h a d e r ). t e xtcontent, 32 fragmentshader : 33 document. getelementbyid ( f r a g m e n t s h a d e r ). t extcontent, 34 b l e n d i n g : THREE. NormalBlending, 35 depthtest : true, 58

61 36 t r a n s p a r e n t : true, 37 s i d e : THREE. DoubleSide, 38 l i n e w i d t h : 2 39 } ) ; 40 // Geometrie und M a t e r i a l zusammenfü hren 41 v a r mesh = new THREE. Mesh ( geometry, m a t e r i a l ) ; 42 // Mesh der Scene h i n z u f ü gen 43 s c e n e. add (mesh ) ; Über die Variable attributes können die Werte für die Farbe und Transparenz eines jeden Punktes einzeln geändert werden. Weitere Informationen zur Transparenz und deren Nutzen sind in Kapitel auf Seite 65 zu finden Auswahl von Elementen Für das Auswählen von Elementen wird der THREE.Raycaster verwendet (siehe: [CABE2014a, Kapitel Raycaster]). Dieser ist ein Helfer-Objekt, das beim Auswählen von Elementen in Three.js unterstützt. Als Parameter benötigt der THREE.Raycaster die Position der Kamera (THREE.Camera), welche den Ursprung repräsentiert. Außerdem wird noch ein Vektor benötigt, der die Blickrichtung darstellt und ein THREE.Projector (siehe: [CABE2014a, Kapitel Projector]). Weitere Informationen zur Unprojekt-Funktion und somit der Funktionsweise des Raycaster [GHOS2010]. 1 function g e t C l i c k e d O b j e c t s ( mousex, mousey ) { 2 v a r v e c t o r = new THREE. Vector3 ( mousex, mousey,. 5 ) ; 3 p r o j e c t o r. u n p r o j e c t V e c t o r ( v e c t o r, camera ) ; 4 5 v e c t o r = v e c t o r. sub ( camera. p o s i t i o n ). n o r m a l i z e ( ) 6 v a r r a y c a s t e r = new THREE. R a y c a s t e r ( camera. p o s i t i o n, v e c t o r ) ; 7 v a r i n t e r s e c t s = 8 r a y c a s t e r. i n t e r s e c t O b j e c t s ( s c e n e. c h i l d r e n, f a l s e ) ; return i n t e r s e c t s ; 11 } intersects enthält ein Array mit Elementen, die der Benutzer ausgewählt haben könnte. Diese Elemente sind der Entfernung von der Kamera nach geordnet. Da aber nur Elemente vom Typ THREE.Mesh relevant sind, muss das Array noch bereinigt werden. Der folgende 59

62 Code-Ausschnitt zeigt die while-schleife zur Bereinigung des Arrays. Diese gehört an die Stelle... (Zeile 9) vom vorhergehenden Listing. 1 while (! ( i n t e r s e c t s [ 0 ]. o b j e c t i n s t a n c e o f THREE. Mesh ) ) { 2 i n t e r s e c t s. remove ( 0 ) ; 3 } Die einzelnen Elemente des Arrays, das zurückgegeben wird, haben immer den gleichen Aufbau. Dieser wird im folgenden Listing dargestellt. 1 { 2 d i s t a n c e : , 3 p o i n t : THREE. Vector3, 4 f a c e : THREE. Face3, 5 f a c e I n d e x : 1399, 6 o b j e c t : THREE. Mesh 7 } distance gibt die Entfernung zur Kamera an und point den Punkt, an dem das Dreieck geschnitten wird. face beinhaltet alle Informationen zu dem ausgewählten Dreieck, wobei faceindex der Index des ausgewählten Dreiecks ist. object stellt das THREE.Mesh dar, zu dem das Dreieck gehört. Diese Informationen werden als Grundlage für das Selektieren verwendet. Es kann damit herausgefunden werden, welches Dreieck vom Benutzer ausgewählt wird. Als nächstes muss eine Möglichkeit geschaffen werden, dem Benutzer eine visuelle Bestätigung seiner Auswahl zu geben. Der erste Ansatz ist, die Farbe des ausgewählten Dreiecks auf Blau zu ändern. Ein Mesh mit ausgewählten Dreiecken ist in Bild 4.4 auf Seite 61 abgebildet. Zu den Informationen vom Dreieck in der Variable face gehören auch die Indizes der drei Punkte (face.a, face.b und face.c). Unter Verwendung dieser können die Punkte in dem Array für die Farben (attributes.customcolor.value) gefunden und geändert werden. 1 a t t r i b u t e s. customcolor. v a l u e [ f a c e. a ] = 2 new THREE. C o l o r (THREE. ColorKeywords. b l u e ) ; 3 a t t r i b u t e s. customcolor. v a l u e [ f a c e. b ] = 4 new THREE. C o l o r (THREE. ColorKeywords. b l u e ) ; 5 a t t r i b u t e s. customcolor. v a l u e [ f a c e. c ] = 6 new THREE. C o l o r (THREE. ColorKeywords. b l u e ) ; 7 a t t r i b u t e s. customcolor. needsupdate = t r u e ; 60

63 Bild 4.4: Mesh mit ausgewählten Dreiecken Auch hier muss mit needsupdate signalisiert werden, dass sich etwas in dem Array geändert hat. Es werden somit alle vom Benutzer ausgewählten Dreiecke in der Farbe Blau markiert. Damit wird allerdings auch das nächste Problem deutlich: Welche Farbe nimmt das Dreieck an, wenn der Benutzer die Markierung aufhebt? Für den Fall, dass keine Lösung vorhanden ist, ist der Fall klar. Es wird die Farbe einfach wieder auf den Standardwert (Grau) zurückgesetzt. Was ist aber, wenn eine Lösung vorhanden ist? Es muss eine Möglichkeit gefunden werden, die Farbe, die durch das Blau überschrieben wurde, wiederherzustellen. Dafür wird die folgende Lösung entwickelt: Die Farben müssen gesichert werden, bevor diese durch das Blau überschrieben werden. Da aber nicht nur die Farben, sondern auch die Transparenz mit dem Selektieren überschrieben wird, müssen diese Werte ebenso gesichert werden. Als Ort für die Sicherung der Werte werden zwei Arrays definiert. selectedelements beinhaltet die Id des gesicherten Elements und selectedelementsbackup die kompletten Werte. Der Aufbau des Objektes für die Datensicherung sieht wie folgt aus: 61

64 1 v a r v a l u e s = { 2 o p a c i t y : { 3 a : g e t C l o n e O f O b j e c t ( a t t r i b u t e s. customopacity. v a l u e [ item. a ] ), 4 b : g e t C l o n e O f O b j e c t ( a t t r i b u t e s. customopacity. v a l u e [ item. b ] ), 5 c : g e t C l o n e O f O b j e c t ( a t t r i b u t e s. customopacity. v a l u e [ item. c ] ) 6 }, 7 c o l o r : { 8 a : g e t C l o n e O f O b j e c t ( a t t r i b u t e s. customcolor. v a l u e [ item. a ] ), 9 b : g e t C l o n e O f O b j e c t ( a t t r i b u t e s. customcolor. v a l u e [ item. b ] ), 10 c : g e t C l o n e O f O b j e c t ( a t t r i b u t e s. customcolor. v a l u e [ item. c ] ) 11 }, 12 i n d i c e s : { 13 a : g e t C l o n e O f O b j e c t ( item. a ), 14 b : g e t C l o n e O f O b j e c t ( item. b ), 15 c : g e t C l o n e O f O b j e c t ( item. c ) 16 } 17 } ; item ist hierbei das zu sichernde Objekt. getcloneofobject() erstellt eine tiefe Kopie von einem Objekt, was bedeutet, dass eine Kopie des Objekts erstellt wird und dieses keine Verbindung mehr zum Quellobjekt hat. Das Gegenteil ist eine flache Kopie. Bei dieser Art der Kopie ist noch eine Verbindung zum Quellobjekt vorhanden. Dieses könnte man erreichen können mit: 1 a : item. a Wird bei einer flachen Kopie etwas im Quellobjekt geändert, wird diese Änderung auch im kopierten Objekt durchgeführt. Das gleiche gilt auch in die andere Richtung. Bei einer tiefen Kopie hingegen ist das nicht der Fall. Dort können Änderungen in den Objekten gemacht werden, ohne dass das andere Objekt mit verändert wird. Da im nächsten Schritt item verändert wird, hätten sich damit auch die Werte in values verändert und die gesicherten Werte wären verloren gegangen, weshalb eine tiefe und keine flache Kopie benötigt wird. Als erstes werden die item.id und values in die dafür vorgesehenen Arrays eingefügt und anschließend diese Werte geändert. 1 s e l e c t e d E l e m e n t s B a c k u p. push ( g e t C l o n e O f O b j e c t ( v a l u e s ) ) ; 2 s e l e c t e d E l e m e n t s. push ( item. i d ) ; 3 4 a t t r i b u t e s. customopacity. v a l u e [ item. a ] = 1. 0 ; 62

65 5 a t t r i b u t e s. customopacity. v a l u e [ item. b ] = 1. 0 ; 6 a t t r i b u t e s. customopacity. v a l u e [ item. c ] = 1. 0 ; 7 a t t r i b u t e s. customopacity. needsupdate = t r u e ; 8 9 a t t r i b u t e s. customcolor. v a l u e [ item. a ] = 10 new THREE. C o l o r (THREE. ColorKeywords. l i g h t b l u e ) ; 11 a t t r i b u t e s. customcolor. v a l u e [ item. b ] = 12 new THREE. C o l o r (THREE. ColorKeywords. l i g h t b l u e ) ; 13 a t t r i b u t e s. customcolor. v a l u e [ item. c ] = 14 new THREE. C o l o r (THREE. ColorKeywords. l i g h t b l u e ) ; 15 a t t r i b u t e s. customcolor. needsupdate = t r u e ; Es ist nun möglich, Elemente zu selektieren und dies dem Benutzer mit der Änderung der Farbe auf Blau zu signalisieren. Elemente müssen jedoch nicht nur selektiert, sondern auch deselektiert werden können. Wie erkennt man, dass ein Punkt bereits selektiert ist? Es ist, wie vorher behandelt, an der blauen Farbe zu erkennen, ob ein Punkt bereits selektiert ist oder nicht. Jedoch was bedeutet es für den Code zur Überprüfung, ob ein Dreieck bereits selektiert ist oder nicht? Es müsste für jedes angeklickte Dreieck überprüft werden, ob die Farbe der einzelnen Punkte THREE.ColorKeywords.lightblue entspricht. Es kann allerdings durchaus vorkommen, dass Dreiecke schon vor dem Selektieren die Farbe blau hatten. Die Unterscheidung zwischen von vornherein blauen und selektierten Punkten ist also ohne weitere Informationen nicht möglich. Es werden bereits alle Ids von selektierten Dreiecken in das Array selectedelements eingefügt. Anstelle die Farbe zu überprüfen, kann hier überprüft werden, ob die id bereits in dem Array vorhanden ist. Ist das der Fall, wird das Element deselektiert. Ist das jedoch nicht der Fall, wird das Element selektiert. Dieser zweite Ansatz funktioniert auch, wenn das Element vor dem Selektieren bereits die Farbe Blau hat. Leider muss hierfür immer das komplette Array durchsucht werden. Auch dieser Ansatz wird wieder verworfen. Es wird ein einfacherer und effizienterer Ansatz verfolgt. Statt das komplette Array nach der id zu durchsuchen, wird jedem Element eine zusätzliche Eigenschaft hinzugefügt. selected heißt diese und kann die Zustände true oder false annehmen. Diese Eigenschaft wird dem Element erst hinzugefügt, wenn es das erste Mal selektiert wird. Vorher ist sie nicht vorhanden. Hier wird sich eine JavaScript- Funktionalität zu Nutze gemacht. Wenn mit einer if-bedingung versucht wird den Wert von einem Objekt oder einer Eigenschaft (hier: selected) abzufragen, dieser aber nicht 63

66 existiert, wird der Wert als false interpretiert. 1 i f ( item. s e l e c t e d ) 2 { 3 // S p r i n g t h i e r h i n wenn Item. s e l e c t e d = t r u e i s t. 4 } e l s e { 5 // S p r i n g t h i e r h i n wenn item. s e l e c t e d noch n i c h t vorhaden i s t 6 // oder aber item. s e l e c t e d = f a l s e i s t. 7 } Es werden alle Elemente nach Abschluss des Selektierens um die Eigenschaft selected erweitert. 1 item. s e l e c t e d = t r u e ; Um ein Element zu deselektieren, müssen die Schritte vom Selektieren umgekehrt werden. Zuerst wird überprüft, ob das Element schon selektiert ist. Dann werden die Werte aus dem Array selectedelementsbackup geladen. Diese werden dem Dreieck dann wieder zugewiesen und abschließend aus dem Array entfernt. 1 function d e s e l e c t I t e m ( item ) { 2 i f ( item. s e l e c t e d ) { 3 v a r i n d e x I d = s c. data. s e l e c t e d E l e m e n t s. indexof ( item. i d ) ; 4 i f ( sc. data. s e l e c t e d E l e m e n t s B a c k u p [ i n d e x I d ] ) { 5 v a r v a l u e s = 6 g e t C l o n e O f O b j e c t ( s e l e c t e d E l e m e n t s B a c k u p [ i n d e x I d ] ) ; 7 a t t r i b u t e s. customopacity. v a l u e [ v a l u e s. i n d i c e s. a ] = 8 g e t C l o n e O f O b j e c t ( v a l u e s. o p a c i t y. a ) ; 9 a t t r i b u t e s. customopacity. v a l u e [ v a l u e s. i n d i c e s. b ] = 10 g e t C l o n e O f O b j e c t ( v a l u e s. o p a c i t y. b ) ; 11 a t t r i b u t e s. customopacity. v a l u e [ v a l u e s. i n d i c e s. c ] = 12 g e t C l o n e O f O b j e c t ( v a l u e s. o p a c i t y. c ) ; 13 a t t r i b u t e s. customopacity. needsupdate = t r u e ; a t t r i b u t e s. customcolor. v a l u e [ v a l u e s. i n d i c e s. a ] = 16 g e t C l o n e O f O b j e c t ( v a l u e s. c o l o r. a ) ; 17 a t t r i b u t e s. customcolor. v a l u e [ v a l u e s. i n d i c e s. b ] = 18 g e t C l o n e O f O b j e c t ( v a l u e s. c o l o r. b ) ; 19 a t t r i b u t e s. customcolor. v a l u e [ v a l u e s. i n d i c e s. c ] = 20 g e t C l o n e O f O b j e c t ( v a l u e s. c o l o r. c ) ; 64

67 21 a t t r i b u t e s. customcolor. needsupdate = t r u e ; 22 item. s e l e c t e d = f a l s e ; 23 s e l e c t e d E l e m e n t s B a c k u p. remove ( i n d e x I d ) ; 24 s e l e c t e d E l e m e n t s. remove ( i n d e x I d ) ; 25 } 26 } 27 } Nachdem die Werte in attributes.customopacity aktualisiert sind, muss noch needs- Update auf true gesetzt werden, um dem Renderer mitzuteilen, dass sich etwas geändert hat. Nachdem es jetzt möglich ist Elemente zu (de)selektieren, wird dieses Kapitel auch abgeschlossen. Es kann damit begonnen werden, Aktionen mit den selektierten Elemente durchzuführen Ausblenden von Elementen Wie bereits weiter oben erwähnt sollte es möglich sein, einen bestimmten Wertebereich ein- bzw. auszublenden. Um diese Funktion umsetzen zu können ist es notwendig, dass für jeden Punkt auch auf den Wert der Lösung zugegriffen werden kann. Die Lösungswerte werden von dem Server immer mit der Struktur zusammen an den Client übertragen. Liegt zuerst keine Lösung vor, so wird der Wert standardmäßig mit 0,5 initialisiert. Diese Werte müssen zwischengespeichert werden. Dafür wird im Client ein Array mit dem Namen points generiert, worin alle Punkte abgespeichert werden. Für jeden Punkt werden die Werte: X-, Y-, Z-Koordinate, Id und (Lösungs-) Wert gespeichert. Da die Arrays points und geometry.vertex in der gleichen Funktion befüllt werden, ist der Index bei beiden gleich. Für Vertex vier können also die Werte an Position Nummer vier im points Array gefunden werden. Dieser Umstand macht es möglich die Transparenz, basierend auf dem ausgewählten Wertebereich, zu schalten. Listing 4.19 zeigt eine Funktion zum Aktualisieren der Transparenz für alle Punkte. Diese hat die zwei Parameter minvalue und maxvalue, welche den Wertebereich eingrenzen. Ein Mesh mit ausgeblendeten Dreiecken wird in Bild 4.5 auf Seite 67 dargestellt. Listing 4.19: Ausblenden von Lösungswerten in einem Bereich 1 function updateopacity ( minvalue, maxvalue ) { 2 f o r ( v a r i = 0, p o i n t ; p o i n t = p o i n t s [ i ] ; i ++) { 3 a t t r i b u t e s. customopacity. v a l u e [ i ] = 4 p o i n t. v a l u e < minvalue p o i n t. v a l u e > maxvalue? 0. 0 : 1. 0 ; 65

68 5 } 6 a t t r i b u t e s. customopacity. needsupdate = t r u e ; 7 } Das Ausblenden von allen selektierten Elementen funktioniert ähnlich. Es müssen auch nicht wie vorher beim Selektieren die Werte erst gesichert werden, da es nur zwei Zustände gibt. 1 function h i d e S e l e c t e d E l e m e n t s ( ) { 2 f o r ( v a r i = 0, i d ; i d = s e l e c t e d E l e m e n t s [ i ] ; i ++) { 3 a t t r i b u t e s. customopacity. v a l u e [ geometry. f a c e s [ i d ]. a ] = 0. 0 ; 4 a t t r i b u t e s. customopacity. v a l u e [ geometry. f a c e s [ i d ]. b ] = 0. 0 ; 5 a t t r i b u t e s. customopacity. v a l u e [ geometry. f a c e s [ i d ]. c ] = 0. 0 ; 6 } 7 a t t r i b u t e s. customopacity. needsupdate = t r u e ; 8 } Nachdem die Werte in attributes.customopacity aktualisiert sind, muss needsupdate auf true gesetzt werden, um dem Renderer mitzuteilen, dass sich etwas geändert hat. Ein weiteres Anwendungsgebiet für das Transparentschalten von Objekten ist das Ausblenden von mehreren Schichten von Dreiecken. Gedacht ist es wie folgt: der Benutzer selektiert einige Dreiecke oder zieht mit der Maus einen Rahmen. Nachdem die Dreiecke ausgewählt sind, können diese über ein Kontext-Menü (Rechts-Klick) ausgeblendet werden. Dies führt dazu, dass der Benutzer ein kleines Stück in das 3D-Modell hereinschauen kann. Eine weitere Einsicht wäre allerdings nicht möglich. Dies ist der Fall, weil die Auswahl- Funktion immer das Element mit der kleinsten Entfernung zur Kamera wählt und das immer dem Element direkt am Rand entspricht. Da das allerdings sicherlich nicht den Anforderungen entspricht was das Ausblenden von Elementen angeht, muss hier noch etwas weiter entwickelt werden. Es soll eine Möglichkeit gefunden werden, Elemente so auszublenden, als würde man ein Loch in das 3D-Modell graben. Der erste Schritt dafür ist, jedem Element, ähnlich wie beim Selektieren, eine neue Eigenschaft zuzuweisen. Auch hier wird diese Eigenschaft erst erstellt, wenn das Element das erste Mal ausgeblendet wird. Die Eigenschaft heißt in diesem Fall invisible, wobei hier die invertierte Version verwendet werden muss. Der Standardwert für alle Elemente ist als false vorbelegt, da diese Eigenschaft standardmäßig nicht existiert. Anschließend muss festgelegt werden, wie der Benutzer diese Funktion benutzen kann. Die linke Maustaste ist bereits mit dem (De)Selektieren eines Elementes (1 Klick), 66

69 Bild 4.5: Mesh mit ausgeblendeten Dreiecken (De)Selektieren von mehreren Elementen (STRG + 1 Klick) und dem Drehen des Objekts (1 Klick und halten) belegt. Mit der rechten Maustaste wird ein Kontextmenü geöffnet, um diverse Funktionen auszuführen. Somit bleibt nur noch die mittlere Maustaste. Gerade aber bei Notebooks kommt es oft zu Problemen mit dieser, da sie meist nur durch einen Klick auf die linke und rechte Maustaste gleichzeitig emuliert werden muss. Deshalb wird ein einzelner Klick mit der linken Maustaste bei gehaltener Shift-Taste als Tastenkombination verwendet. Zuerst wird die Funktion, die bei einem Klick mit der linken Maustaste aufgerufen wird, erweitert. Wenn der Klick im WebGL-Fenster (renderer.domelement), die Maustaste die linke Maustaste ist, die Maus nicht in Bewegung ist und die Shift- aber nicht die STRG-Taste gedrückt, wird kann damit begonnen werden, das Element zum Ausblenden zu ermitteln. Dafür werden als erstes die angeklickten Elemente abgefragt und anschließend alle bereits ausgeblendeten Elemente aus der Liste entfernt. 1 i f ( e v e n t. t a r g e t == r e n d e r e r. domelement && e v e n t. button == 0 2 &&! mousewasmoved && e v e n t. s h i f t K e y &&! e v e n t. c t r l K e y ) { 3 v a r i n t e r s e c t s = g e t C l i c k e d O b j e c t s ( mousex, mousey ) ; 67

Websockets: Leichtgewichtige Verbindungen für Web-Applikationen

Websockets: Leichtgewichtige Verbindungen für Web-Applikationen Websockets: Leichtgewichtige Verbindungen für Web-Applikationen Seite: 1 / 16 Über mich Stefan Neufeind Mit-Geschäftsführer der SpeedPartner GmbH aus Neuss ein Internet-Service-Provider (ISP) Individuelle

Mehr

Proseminar: Website-Management-Systeme

Proseminar: Website-Management-Systeme Proseminar: Website-Management-Systeme Thema: Web: Apache/Roxen von Oliver Roeschke email: o_roesch@informatik.uni-kl.de Gliederung: 1.) kurze Einleitung 2.) Begriffsklärung 3.) Was ist ein Web? 4.) das

Mehr

eytron VMS Webanwendung Fehlersuche und -Behebung

eytron VMS Webanwendung Fehlersuche und -Behebung eytron VMS Webanwendung Fehlersuche und -Behebung 2009 ABUS Security-Center GmbH & Co. KG, Alle Rechte vorbehalten Diese Anleitung soll Ihnen Unterstützung für den Fall geben, dass die Webanwendung nach

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

Übersicht. Was ist FTP? Übertragungsmodi. Sicherheit. Öffentliche FTP-Server. FTP-Software

Übersicht. Was ist FTP? Übertragungsmodi. Sicherheit. Öffentliche FTP-Server. FTP-Software FTP Übersicht Was ist FTP? Übertragungsmodi Sicherheit Öffentliche FTP-Server FTP-Software Was ist FTP? Protokoll zur Dateiübertragung Auf Schicht 7 Verwendet TCP, meist Port 21, 20 1972 spezifiziert Übertragungsmodi

Mehr

Einführung in die Cross-Plattform Entwicklung Das Intel App Framework

Einführung in die Cross-Plattform Entwicklung Das Intel App Framework Einführung in die Cross-Plattform Entwicklung Das Intel App Framework Einführung Dieses Hands-on-Lab (HOL) macht den Leser mit dem Intel App Framework vom Intel XDK vertraut. Es wird Schritt für Schritt

Mehr

Schnellanleitung: Bilder für das Internet optimieren

Schnellanleitung: Bilder für das Internet optimieren Inhaltsverzeichnis Inhaltsverzeichnis... 1 Schnellanleitung: Bilder für das Internet optimieren... 1 Bilder für das Internet optimieren... 2 Auflösung bei Grafiken für Printmedien... 2 Auflösung bei Grafiken

Mehr

Agenda. Ingo Ebel (ie007) Benjamin Müller (bm032) Was ist AJAX? Sicherheit Vor- und Nachteile. AJAX Frameworks. Wozu benötigt Client/Server

Agenda. Ingo Ebel (ie007) Benjamin Müller (bm032) Was ist AJAX? Sicherheit Vor- und Nachteile. AJAX Frameworks. Wozu benötigt Client/Server AJAX Agenda Ingo Ebel (ie007) Was ist AJAX? Wozu benötigt Client/Server Sicherheit Vor- und Nachteile Benjamin Müller (bm032) AJAX Frameworks GWT ATF Ingo Ebel - ie007 2 Web 2.0 Ingo Ebel - ie007 3 Ingo

Mehr

Streaming Protokolle Jonas Hartmann

Streaming Protokolle Jonas Hartmann Streaming Protokolle Jonas Hartmann 1 Streaming Protokolle Inhaltsverzeichnis 1. Definition / Anwendungsfälle 2. Offizielle RFC Streaming Protokolle 3. Ein wichtiges proprietäres Protokoll 4. Konkreter

Mehr

Zugriff auf die Installation mit dem digitalstrom- Konfigurator mit PC und Mac

Zugriff auf die Installation mit dem digitalstrom- Konfigurator mit PC und Mac Zugriff auf die Installation mit dem digitalstrom- Konfigurator mit PC und Mac Zusatz zum digitalstrom Handbuch VIJ, aizo ag, 15. Februar 2012 Version 2.0 Seite 1/10 Zugriff auf die Installation mit dem

Mehr

Die Cargo Plattform bietet einen sicheren und einfachen Datentransfer mit einem modernen Web- Interface.

Die Cargo Plattform bietet einen sicheren und einfachen Datentransfer mit einem modernen Web- Interface. Die Cargo Plattform bietet einen sicheren und einfachen Datentransfer mit einem modernen Web- Interface. Inhaltsverzeichnis Erste Schritte Anmelden 2 Startseite 3 Dateimanager 4 CargoLink 5 Freigaben 6

Mehr

0. Inhaltsverzeichnis

0. Inhaltsverzeichnis 0. Inhaltsverzeichnis 0. Inhaltsverzeichnis...1 1. Kurze Einführung WebService Architektur...2 1.1 Synchrones Modell:...2 1.2 Asynchrones Modell:...2 1.3 Vorteile:...3 1.4 Voraussetzungen...3 2. Testseite

Mehr

Sicherheit in Rich Internet Applications

Sicherheit in Rich Internet Applications Sicherheit in Rich Internet Applications Florian Kelbert 14.02.2008 Seite 2 Sicherheit in Rich Internet Applications Florian Kelbert 14.02.2008 Inhaltsverzeichnis Grundlagen Ajax und Mashups Adobe Flash-Player

Mehr

TCP/UDP. Transport Layer

TCP/UDP. Transport Layer TCP/UDP Transport Layer Lernziele 1. Wozu dient die Transportschicht? 2. Was passiert in der Transportschicht? 3. Was sind die wichtigsten Protkolle der Transportschicht? 4. Wofür wird TCP eingesetzt?

Mehr

Message Oriented Middleware am Beispiel von XMLBlaster

Message Oriented Middleware am Beispiel von XMLBlaster Message Oriented Middleware am Beispiel von XMLBlaster Vortrag im Seminar XML und intelligente Systeme an der Universität Bielefeld WS 2005/2006 Vortragender: Frederic Siepmann fsiepman@techfak.uni bielefeld.de

Mehr

Datenbank-basierte Webserver

Datenbank-basierte Webserver Datenbank-basierte Webserver Datenbank-Funktion steht im Vordergrund Web-Schnittstelle für Eingabe, Wartung oder Ausgabe von Daten Datenbank läuft im Hintergrund und liefert Daten für bestimmte Seiten

Mehr

3827260108 Private Homepage vermarkten So laden Sie Ihre Website auf den Server Das lernen Sie in diesem Kapitel: n So funktioniert FTP n Diese FTP-Programme gibt es n So laden Sie Ihre Website mit WS-FTP

Mehr

GeoShop Netzwerkhandbuch

GeoShop Netzwerkhandbuch Technoparkstrasse 1 8005 Zürich Tel.: 044 / 350 10 10 Fax.: 044 / 350 10 19 GeoShop Netzwerkhandbuch Zusammenfassung Diese Dokumentation beschreibt die Einbindung des GeoShop in bestehende Netzwerkumgebungen.

Mehr

1 Installationen. 1.1 Installationen unter Windows

1 Installationen. 1.1 Installationen unter Windows 1 Installationen Dieses Kapitel beschreibt die Installationen, die für die Nutzung von PHP und MySQL unter Windows, unter Ubuntu Linux und auf einem Mac mit OS X notwendig sind. 1.1 Installationen unter

Mehr

Rechnernetze Übung 12

Rechnernetze Übung 12 Rechnernetze Übung 12 Frank Weinhold Professur VSR Fakultät für Informatik TU Chemnitz Juli 2011 Sie kennen sicherlich sogenannte Web-Mailer, also WWW-Oberflächen über die Sie Emails lesen und vielleicht

Mehr

Sachwortverzeichnis... 251

Sachwortverzeichnis... 251 Inhalt Vorwort... V 1 WWW World Wide Web... 1 1.1 Das Internet Infrastruktur und Administration... 2 1.2 Datenübertragung... 4 1.3 Sprachen im Web... 6 1.4 Webseiten... 7 1.4.1 Clientseitige Dynamik...

Mehr

Web Datei Formate GIF JPEG PNG SVG. Einleitung. GIF Graphic Interchange Format. JPEG Joint Photographic Expert Group. PNG Portable Network Graphic

Web Datei Formate GIF JPEG PNG SVG. Einleitung. GIF Graphic Interchange Format. JPEG Joint Photographic Expert Group. PNG Portable Network Graphic Einleitung Graphic Interchange Format Joint Photographic Expert Group Portable Network Graphic scalabel Vector Graphic Fazit Übungsaufgabe Speichern Einleitung Das Web ist eines der wichtigsten Medien

Mehr

Microsoft PowerPoint 2013 YouTube-Video einfügen

Microsoft PowerPoint 2013 YouTube-Video einfügen Hochschulrechenzentrum Justus-Liebig-Universität Gießen Microsoft PowerPoint 2013 YouTube-Video einfügen YouTube-Video einfügen in PowerPoint 2013 Seite 1 von 6 Inhaltsverzeichnis Einleitung... 2 Vorbereitungen...

Mehr

SOAP Simple Object Access Protocol

SOAP Simple Object Access Protocol Informatikseminar Tobias Briel Überblick 1. Einführung - was ist? 2. Middlewaretechnologie 3. Aufbau von Nachrichten 4. Vergleiche 5. Beispielanwendung 6. Zusammenfassung 1 Einführung was ist Soap? neue

Mehr

Konzept eines Datenbankprototypen. 30.06.2003 Folie 1 Daniel Gander / Gerhard Schrotter

Konzept eines Datenbankprototypen. 30.06.2003 Folie 1 Daniel Gander / Gerhard Schrotter Konzept eines Datenbankprototypen 30.06.2003 Folie 1 Daniel Gander / Gerhard Schrotter Inhalt (1) Projektvorstellung & Projektzeitplan Softwarekomponenten Detailierte Beschreibung der System Bausteine

Mehr

Browserbasiertes, kollaboratives Whiteboard

Browserbasiertes, kollaboratives Whiteboard WS 2011/12 Bachelorarbeit Browserbasiertes, kollaboratives Whiteboard Sebastian Dorn 1 von 21 Inhalt 1. Motivation 2. Analyse 3. Design 4. Evaluation 5. Fazit Inhalt 2 von 21 Motivation Zusammenarbeit

Mehr

Managed VPSv3 Was ist neu?

Managed VPSv3 Was ist neu? Managed VPSv3 Was ist neu? Copyright 2006 VERIO Europe Seite 1 1 EINFÜHRUNG 3 1.1 Inhalt 3 2 WAS IST NEU? 4 2.1 Speicherplatz 4 2.2 Betriebssystem 4 2.3 Dateisystem 4 2.4 Wichtige Services 5 2.5 Programme

Mehr

1.) Nennen Sie Aufgaben und mögliche Dienste der Transportschicht (Transport Layer) des ISO/OSI-Schichtenmodells.

1.) Nennen Sie Aufgaben und mögliche Dienste der Transportschicht (Transport Layer) des ISO/OSI-Schichtenmodells. Übung 7 1.) Nennen Sie Aufgaben und mögliche Dienste der Transportschicht (Transport Layer) des ISO/OSI-Schichtenmodells. 2.) Charakterisieren Sie kurz das User Datagram Protokoll (UDP) aus der Internetprotokollfamilie

Mehr

NEWpixi* API und die Umstellung auf REST. Freitag, 3. Mai 13

NEWpixi* API und die Umstellung auf REST. Freitag, 3. Mai 13 NEWpixi* API und die Umstellung auf REST Fakten NEWpixi* API Technik REST-basierend.NET Webservice IIS Webserver Release 31. August 2013, zusammen mit dem NEWpixi* ELI Release Legacy API und erste NEWpixi*

Mehr

OpenGL. (Open Graphic Library)

OpenGL. (Open Graphic Library) OpenGL (Open Graphic Library) Agenda Was ist OpenGL eigentlich? Geschichte Vor- und Nachteile Arbeitsweise glscene OpenGL per Hand Debugging Trend Was ist OpenGL eigentlich? OpenGL ist eine Spezifikation

Mehr

Bin ich fit für myconvento?

Bin ich fit für myconvento? Bin ich fit für myconvento? Sie planen den Einsatz unserer innovativen Kommunikationslösung myconvento und fragen sich gerade, ob Ihr Rechner die Anforderungen erfüllt? Hier erfahren Sie mehr. Inhalt Was

Mehr

Zeiterfassung-Konnektor Handbuch

Zeiterfassung-Konnektor Handbuch Zeiterfassung-Konnektor Handbuch Inhalt In diesem Handbuch werden Sie den Konnektor kennen sowie verstehen lernen. Es wird beschrieben wie Sie den Konnektor einstellen und wie das System funktioniert,

Mehr

Gefahren aus dem Internet 6 Aktive Angriffe April 2010

Gefahren aus dem Internet 6 Aktive Angriffe April 2010 6 Aktive Angriffe Lernziele Sie können grob erklären, wie ein Angreifer in Ihren Computer eindringen kann. Sie können herausfinden, welche Ports auf Ihrem Computer offen sind. Sie wissen, warum der Einsatz

Mehr

Einfügen von Bildern innerhalb eines Beitrages

Einfügen von Bildern innerhalb eines Beitrages Version 1.2 Einfügen von Bildern innerhalb eines Beitrages Um eigene Bilder ins Forum einzufügen, gibt es zwei Möglichkeiten. 1.) Ein Bild vom eigenem PC wird auf den Webspace von Baue-die-Bismarck.de

Mehr

Anwendungsprotokolle: HTTP, POP, SMTP

Anwendungsprotokolle: HTTP, POP, SMTP Anwendungsprotokolle: HTTP, POP, SMTP TCP? UDP? Socket? eingesetzt, um Webseiten zu übertragen Zustandslos Nutzt TCP Client schickt Anfrage ( HTTP-Request ) an Server, Server schickt daraufhin Antwort

Mehr

Klausur Kommunikation I. Sommersemester 2003. Dipl.-Ing. T. Kloepfer

Klausur Kommunikation I. Sommersemester 2003. Dipl.-Ing. T. Kloepfer Kommunikation I 1 Klausur Kommunikation I Sommersemester 2003 Dipl.-Ing. T. Kloepfer Bearbeitungsinformationen Aufbau der Klausur Die Klausur ist wie folgt aufgebaut: Die Klausur ist in 18 Aufgaben unterteilt.

Mehr

Technische Voraussetzungen Stand: 29. Juli 2014

Technische Voraussetzungen Stand: 29. Juli 2014 Technische Voraussetzungen Stand: 29. Juli 2014 FineSolutions AG Culmannstrasse 37 8006 Zürich Telefon +41 44 245 85 85 Telefax +41 44 245 85 95 support@finesolutions.ch Inhaltsverzeichnis 1 Einführung...

Mehr

Entwicklung und Integration mobiler Anwendungen. Oracle Deutschland B.V. & Co. KG

Entwicklung und Integration mobiler Anwendungen. <Speaker> Oracle Deutschland B.V. & Co. KG Entwicklung und Integration mobiler Anwendungen Oracle Deutschland B.V. & Co. KG Global Users (Millions) Der Trend ist eindeutig. Trend zu mobilen Endgeräten Wachstum des mobilen Datenverkehrs

Mehr

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1)

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) 1 FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) In dieser Kurseinheit geht es um verteilte Anwendungen, bei denen wir sowohl ein Client- als auch ein

Mehr

Fortgeschrittene Servlet- Techniken. Ralf Gitzel ralf_gitzel@hotmail.de

Fortgeschrittene Servlet- Techniken. Ralf Gitzel ralf_gitzel@hotmail.de Fortgeschrittene Servlet- Techniken Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht Servlet Initialisierung Attribute und Gültigkeitsbereiche Sessions

Mehr

IT- und Medientechnik

IT- und Medientechnik IT- und Medientechnik Vorlesung 11: 19.12.2014 Wintersemester 2014/2015 h_da, Lehrbeauftragter Themenübersicht der Vorlesung Hard- und Software Hardware: CPU, Speicher, Bus, I/O,... Software: System-,

Mehr

Angreifbarkeit von Webapplikationen

Angreifbarkeit von Webapplikationen Vortrag über die Risiken und möglichen Sicherheitslücken bei der Entwicklung datenbankgestützter, dynamischer Webseiten Gliederung: Einführung technische Grundlagen Strafbarkeit im Sinne des StGB populäre

Mehr

Aktuelle Sicherheitsprobleme im Internet: Angriffe auf Web-Applikationen

Aktuelle Sicherheitsprobleme im Internet: Angriffe auf Web-Applikationen FAEL-Seminar Aktuelle Sicherheitsprobleme im Internet: Angriffe auf Web-Applikationen Prof. Dr. Marc Rennhard Institut für angewandte Informationstechnologie InIT ZHAW Zürcher Hochschule für Angewandte

Mehr

Systemanforderungen Verlage & Akzidenzdruck

Systemanforderungen Verlage & Akzidenzdruck OneVision Software AG Inhalt Asura 9.5, Asura Pro 9.5, Garda 5.0...2 PlugBALANCEin 6.5, PlugCROPin 6.5, PlugFITin 6.5, PlugRECOMPOSEin 6.5, PlugSPOTin 6.5,...2 PlugTEXTin 6.5, PlugINKSAVEin 6.5, PlugWEBin

Mehr

!"# $ % Internet Protokolle: HTTP 1/38

!# $ % Internet Protokolle: HTTP 1/38 !"# $ % Internet Protokolle: HTTP 1/38 1 Themenübersicht Schichtenmodell Gopher /FTP Statistik URL Einleitung Anwendungsablauf Beispiel mit Telnet Request, Response Anfragemethoden header Negotiation Proxyserver

Mehr

Windows SharePoint Services als gemeinsamen Dateispeicher einrichten

Windows SharePoint Services als gemeinsamen Dateispeicher einrichten Windows SharePoint Services als gemeinsamen Dateispeicher einrichten (Engl. Originaltitel: Setting up Windows SharePoint Services as a Collaborative File Store) Dustin Friesenhahn Veröffentlicht: August

Mehr

Was ist SVG? Inhalt: Allgemeines zu SVG Besondere Merkmale Vor- und Nachteile Dateiformat Standardobjekte Koordinatensystem Beispiele Links

Was ist SVG? Inhalt: Allgemeines zu SVG Besondere Merkmale Vor- und Nachteile Dateiformat Standardobjekte Koordinatensystem Beispiele Links Was ist SVG? Was ist SVG? Inhalt: Allgemeines zu SVG Besondere Merkmale Vor- und Nachteile Dateiformat Standardobjekte Koordinatensystem Beispiele Links SVG: Allgemeines zu SVG SVG = Scalable Vector Graphics

Mehr

Skyfillers Hosted SharePoint. Kundenhandbuch

Skyfillers Hosted SharePoint. Kundenhandbuch Skyfillers Hosted SharePoint Kundenhandbuch Kundenhandbuch Inhalt Generell... 2 Online Zugang SharePoint Seite... 2 Benutzerpasswort ändern... 2 Zugriff & Einrichtung... 3 Windows... 3 SharePoint als

Mehr

CBS-Heidelberg Helpdesk Filr-Dokumentation S.1

CBS-Heidelberg Helpdesk Filr-Dokumentation S.1 CBS-Heidelberg Helpdesk Filr-Dokumentation S.1 Dokumentation der Anwendung Filr von Novell G Informationen zu Filr, die über diese Dokumentation hinausgehen, finden Sie im Internet unter: http://www.novell.com/de-de/documentation/novell-filr-1-1/

Mehr

Dokumentation zum Projekt Mail-Adapter in SAP PI. 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696

Dokumentation zum Projekt Mail-Adapter in SAP PI. 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696 Dokumentation zum Projekt Mail-Adapter in SAP PI 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696 Inhalt 1. Einleitung... 2 2. Vorgehen... 3 1. Datentyp für die Mail einrichten... 3 2. Message Typen

Mehr

Vorbereiten des ReadyNAS Duo

Vorbereiten des ReadyNAS Duo Vorbereiten des ReadyNAS Duo In diesem Installationshandbuch wird beschrieben, wie das ReadyNAS Duo an ein Netzwerk angeschlossen wird ( RAIDar unter Windows installieren und Installieren des RAIDar-Assistenten

Mehr

Dr. Martin Brändle. ETH Zürich Informationszentrum Chemie Biologie Pharmazie Wolfgang-Pauli-Str. 10, HCI J 57.4 8093 Zürich

Dr. Martin Brändle. ETH Zürich Informationszentrum Chemie Biologie Pharmazie Wolfgang-Pauli-Str. 10, HCI J 57.4 8093 Zürich ETH Zürich Informationszentrum Chemie Biologie Pharmazie Wolfgang-Pauli-Str. 10, HCI J 57.4 8093 Zürich Ausgangspunkt: Rauminformation Was steckt dahinter? DB: Datenklassen Plan-bezogen Bibliotheks-bezogen

Mehr

VWA Rhein-Neckar Dipl.-Ing. Thomas Kloepfer. Kommunikation I (Internet) Übung 4 PHP

VWA Rhein-Neckar Dipl.-Ing. Thomas Kloepfer. Kommunikation I (Internet) Übung 4 PHP VWA Rhein-Neckar Dipl.-Ing. Thomas Kloepfer Kommunikation I (Internet) Übung 4 PHP SS 2004 Inhaltsverzeichnis 1. PHP die serverseitige Programmiersprache...1 1.1. PHP - Bereiche in HTML definieren...1

Mehr

Systemvoraussetzungen und Installation

Systemvoraussetzungen und Installation Systemvoraussetzungen und Installation Inhaltsverzeichnis Inhaltsverzeichnis... 2 1. Einleitung... 2 2. Einzelarbeitsplatzinstallation... 3 3. Referenz: Client/Server-Installation... 5 3.1. Variante A:

Mehr

Version 4.4. security.manager. Systemvoraussetzungen

Version 4.4. security.manager. Systemvoraussetzungen Version 4.4 security.manager Systemvoraussetzungen Version 4.4 Urheberschutz Der rechtmäßige Erwerb der con terra Softwareprodukte und der zugehörigen Dokumente berechtigt den Lizenznehmer zur Nutzung

Mehr

Gefahren aus dem Internet 1 Grundwissen April 2010

Gefahren aus dem Internet 1 Grundwissen April 2010 1 Grundwissen Voraussetzungen Sie haben das Internet bereits zuhause oder an der Schule genutzt. Sie wissen, was ein Provider ist. Sie wissen, was eine URL ist. Lernziele Sie wissen, was es braucht, damit

Mehr

Installationsleitfaden kabelsafe storage mit FileZilla Client Programm

Installationsleitfaden kabelsafe storage mit FileZilla Client Programm Installationsleitfaden kabelsafe storage mit FileZilla Client Programm Installationsanleitung kabelsafe storage unter Verwendung des kostenlos unter verschiedenen Betriebssystemplattformen (Windows, Apple

Mehr

Vom HMI zum WebSCADA Portal

Vom HMI zum WebSCADA Portal Vom HMI zum WebSCADA Portal Teil 1. Skalierbare webbasierende Visualisierungsplattform: Das Bedienpanel als Basis Marcel Bühner Schlagworte wie Industrie 4.0, IoT (Internet of Things), Automation in the

Mehr

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten Aktuelle Themen der Wirtschaftsinformatik Zusammenfassung 09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten 1 Serverseitige Webprogrammierung

Mehr

Anleitung DONATSCH WebShare V02

Anleitung DONATSCH WebShare V02 Anleitung DONATSCH WebShare V02 1. Einleitung Ihr von uns gescanntes Objekt kann auf Wunsch via Webbrowser abgerufen werden. Sämtliche Scans sind einsehbar und es können Messungen darin durchgeführt werden.

Mehr

FTP HOWTO. zum Upload von Dateien auf Webserver. Stand: 01.01.2011

FTP HOWTO. zum Upload von Dateien auf Webserver. Stand: 01.01.2011 FTP HOWTO zum Upload von Dateien auf Webserver Stand: 01.01.2011 Copyright 2002 by manitu. Alle Rechte vorbehalten. Alle verwendeten Bezeichnungen dienen lediglich der Kennzeichnung und können z.t. eingetragene

Mehr

Quality Point München

Quality Point München Quality Point München Test webbasierter Applikationen - Vorgehen, Instrumente, Probleme Gestern habe ich mich wieder über eine fehlerhafte Webanwendung geärgert. Muss das sein? Test ist halt auch hier

Mehr

Web 2.0 Software-Architekturen

Web 2.0 Software-Architekturen Web 2.0 Software-Architekturen Servlets als Controller einer MVC Web Architektur Prof. Dr. Nikolaus Wulff HTTP und HTML Das HyperText TransferProtokoll (HTTP) beschreibt eine einfache verbindungslose Kommunikation,

Mehr

ISA Server 2004 HTTP Filter - Von Marc Grote

ISA Server 2004 HTTP Filter - Von Marc Grote Seite 1 von 11 ISA Server 2004 HTTP Filter - Von Marc Grote Die Informationen in diesem Artikel beziehen sich auf: Microsoft ISA Server 2004 Einleitung In diesem Artikel erläutere ich die Konfiguration

Mehr

Makologa Touré Damian Gawenda

Makologa Touré Damian Gawenda Vortrag von Makologa Touré Damian Gawenda im ITT am 08. August 2006 07.08.06 Makologa Touré Damian Gawenda 1 Übersicht Was ist ein WMS? Web-Technologien Wie installiere ich einen Web-Map-Server? 07.08.06

Mehr

Übersetzung von TeamLab in andere Sprachen

Übersetzung von TeamLab in andere Sprachen Verfügbare Sprachen TeamLab wurde in die folgenden Sprachen übersetzt (Stand: Januar 2012): Vollständig übersetzt Teilweise übersetzt Englisch Deutsch Französisch Spanisch Russisch Lettisch Italienisch

Mehr

Multivariate Tests mit Google Analytics

Multivariate Tests mit Google Analytics Table of Contents 1. Einleitung 2. Ziele festlegen 3. Einrichtung eines Multivariate Tests in Google Analytics 4. Das JavaScript 5. Die Auswertung der Ergebnisse Multivariate Tests mit Google Analytics

Mehr

Dynamische Webseiten mit PHP 1

Dynamische Webseiten mit PHP 1 Dynamische Webseiten mit PHP 1 Webserver, PHP und MYSQL Ein Webserver dient dazu, Internetseiten an PCs zu senden, von denen sie aufgerufen werden. Beispiel: Sie tippen im Browser www.fosbosweiden.de ein.

Mehr

Aktuelle Sicherheitsprobleme im Internet: Angriffe auf Web-Applikationen

Aktuelle Sicherheitsprobleme im Internet: Angriffe auf Web-Applikationen Aktuelle Sicherheitsprobleme im Internet: Angriffe auf Web-Applikationen Dr. Marc Rennhard Institut für angewandte Informationstechnologie Zürcher Hochschule Winterthur marc.rennhard@zhwin.ch Angriffspunkt

Mehr

Motivation. Inhalt. URI-Schemata (1) URI-Schemata (2)

Motivation. Inhalt. URI-Schemata (1) URI-Schemata (2) 14. URIs Uniform Resource Identifier 14-1 14. URIs Uniform Resource Identifier 14-2 Motivation Das WWW ist ein Hypermedia System. Es enthält: Resourcen (Multimedia Dokumente) Verweise (Links) zwischen

Mehr

Bilddateien. Für die Speicherung von Bilddaten existieren zwei grundsätzlich unterschiedliche Verfahren. Bilder können als

Bilddateien. Für die Speicherung von Bilddaten existieren zwei grundsätzlich unterschiedliche Verfahren. Bilder können als Computerdateien Alle Dateien auf dem Computer, egal ob nun Zeichen (Text), Bilder, Töne, Filme etc abgespeichert wurden, enthalten nur eine Folge von Binärdaten, also Nullen und Einsen. Damit die eigentliche

Mehr

Call Button / HTTP - Systembeschreibung

Call Button / HTTP - Systembeschreibung Call Button / HTTP - Systembeschreibung Detlef Reil, 14.03.2004, zu Call Button, Version 040127, V1.50 Beta! Software System Für die Kommunikation zwischen den Call Buttons und der Applikation war bisher

Mehr

Installation Anleitung für JTheseus und MS SQL Server 2000

Installation Anleitung für JTheseus und MS SQL Server 2000 Installation Anleitung für JTheseus und MS SQL Server 2000 Inhaltsverzeichnis 1 Installation der Datenbank 3 1.1 Erstellen der Datenbank 3 1.2 Tabellen und Minimal Daten einlesen 4 1.3 Benutzer JTheseus

Mehr

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit 1 Hochverfügbarkeit Lernziele: Network Load Balancing (NLB) Failover-Servercluster Verwalten der Failover Cluster Rolle Arbeiten mit virtuellen Maschinen Prüfungsanforderungen von Microsoft: Configure

Mehr

www.uni-math.gwdg.de/linuxuebung

www.uni-math.gwdg.de/linuxuebung 14 Netzwerküberwachung und -steuerung Überblick SNMP Simple Network Management Protocol Datendefinitionen SNMP Implementierungen unter Linux Kommandos zur Datenbeschaffung Konfiguration des Net-SNMP Agenten

Mehr

Secure Socket Layer (SSL) 1: Allgemeiner Überblick. Gilt für die Geräte: HL-4040CN HL-4050CDN HL-4070CDW DCP-9040CN DCP-9045CDN MFC-9440CN MFC-9840CDW

Secure Socket Layer (SSL) 1: Allgemeiner Überblick. Gilt für die Geräte: HL-4040CN HL-4050CDN HL-4070CDW DCP-9040CN DCP-9045CDN MFC-9440CN MFC-9840CDW Secure Socket Layer (SSL) Gilt für die Geräte: HL-4040CN HL-4050CDN HL-4070CDW DCP-9040CN DCP-9045CDN MFC-9440CN MFC-9840CDW Inhalt 1) Allgemeiner Überblick 2) Kurzer geschichtlicher Rückblick 3) Vorteile

Mehr

5.4 Die Benachrichtigung (Notification)

5.4 Die Benachrichtigung (Notification) 160 Bekannte Probleme Windows Phone Im Emulator wird immer die Connection.UNKNOWN zurückgegeben. ios und Bada Es wird leider nur unterschieden, ob es eine mobile oder WiFi-Verbindung gibt. Der Grad der

Mehr

Generieren von Nodelock Lizenzen. Hilfe für www.intergraph.com/sgi/license

Generieren von Nodelock Lizenzen. Hilfe für www.intergraph.com/sgi/license Generieren von Nodelock Lizenzen Hilfe für www.intergraph.com/sgi/license SG&I Lizenzen April 2010 2010 Intergraph SG&I Deutschland GmbH. Alle Rechte vorbehalten. Der Inhalt dieses Dokuments ist urheberrechtlich

Mehr

SNMP und der MIB- Browser von MG-Soft

SNMP und der MIB- Browser von MG-Soft SNMP und der MIB- Browser von MG-Soft 1. SNMP 1.1 Was ist SNMP 1.2 Historie von SNMP 1.3 Einordnung in das OSI-Modell 1.4 Die Architektur von SNMP 1.5 Kommunikation von SNMP 1.6 SNMP-PDUs PDUs 2. MIB und

Mehr

Präsentation. homevisu Familie. Peter Beck. Juni 2011. www.p-b-e.de. 2011 p b e Peter Beck 1

Präsentation. homevisu Familie. Peter Beck. Juni 2011. www.p-b-e.de. 2011 p b e Peter Beck 1 Präsentation homevisu Familie Peter Beck Juni 2011 2011 p b e Peter Beck 1 Funktionensumfang Der Funktionsumfang das provisu Framework. Modular und durch Plug-In erweiterbar / anpassbar. Plug-In Schnittstelle

Mehr

AJAX SSL- Wizard Referenz

AJAX SSL- Wizard Referenz AJAX SSL- Wizard Referenz Version 1.0.2+ - 04.04.2011 Präambel Die vorliegende Dokumentation beschreibt den AJAX basierten SSL- Wizard der CertCenter AG. Der SSL- Wizard kann mit wenigen Handgriffen nahtlos

Mehr

Bildbearbeitung Irfanview

Bildbearbeitung Irfanview Bildbearbeitung Irfanview Mit diesem Schulungs-Handbuch lernen Sie Bilder für das Internet zu bearbeiten mit dem Gratis-Programm IrfanView Version 1.2 Worldsoft AG 1. Kurzübersicht des Schulungs-Lehrgangs

Mehr

Anleitung. Supplier Web Portal

Anleitung. Supplier Web Portal Anleitung Supplier Web Portal 9. April 2013 Inhaltsverzeichnis 2 / 12 Inhaltsverzeichnis 1 Was ist das Supplier Web Portal von? 3 2 Systemanforderungen 3 3 Am Supplier Web Portal anmelden 4 4 Daten empfangen

Mehr

Avira Support Collector. Kurzanleitung

Avira Support Collector. Kurzanleitung Avira Support Collector Kurzanleitung Inhaltsverzeichnis 1. Einleitung... 3 2. Ausführung des Avira Support Collectors... 3 2.1 Auswahl des Modus...4 3. Einsammeln der Informationen... 5 4. Auswertung

Mehr

CloudMatic V1.0. Inhalt

CloudMatic V1.0. Inhalt CloudMatic V1.0 Inhalt Einleitung... 2 CCUs hinzufügen... 3 meine-homematic.de... 4 Eigenes VPN... 4 View Editor... 5 Übersicht... 5 Allgemeine Einstellungen... 6 Kanäle hinzufügen... 6 Spezielle Kanäle...

Mehr

crm-now/ps Anwenderhandbuch für die Thunderbird Erweiterung Zweite Ausgabe

crm-now/ps Anwenderhandbuch für die Thunderbird Erweiterung Zweite Ausgabe crm-now/ps Anwenderhandbuch für die Thunderbird Erweiterung Zweite Ausgabe crm-now/ps: Copyright 2006 crm-now Versionsgeschichte Version 02 08.09.2006 Release Version Version 01 16.06.2005 crm-now c/o

Mehr

Beschreibung Mobile Office

Beschreibung Mobile Office Beschreibung Mobile Office 1. Internet / Netz Zugriff Für die Benutzung von Mobile Office ist lediglich eine Internet oder Corporate Netz Verbindung erforderlich. Nach der Verbindungsherstellung kann über

Mehr

Sophos Anti-Virus. Felizitas Heinebrodt. Technische Hochschule Nürnberg Rechenzentrum Kesslerplatz 12, 90489 Nürnberg. Version 12 September 2014

Sophos Anti-Virus. Felizitas Heinebrodt. Technische Hochschule Nürnberg Rechenzentrum Kesslerplatz 12, 90489 Nürnberg. Version 12 September 2014 Sophos Anti-Virus Felizitas Heinebrodt Technische Hochschule Nürnberg Rechenzentrum Kesslerplatz 12, 90489 Nürnberg Version 12 September 2014 DokID: sophos Vers. 12, 20.08.2015, RZ/THN Informationen des

Mehr

Systemvoraussetzungen 14.0

Systemvoraussetzungen 14.0 Systemvoraussetzungen 14.0 CMIAXIOMA - CMISTAR 29. Oktober 2014 Systemvoraussetzungen 14.0 Seite 2 / 12 Inhaltsverzeichnis 1 Allgemeines... 3 1.1 Support Lifecycle Policy... 3 1.2 Test Policy... 3 1.3

Mehr

SVG Skalierbare Vektorgrafiken im Netz

SVG Skalierbare Vektorgrafiken im Netz SVG Skalierbare Vektorgrafiken im Netz Weckung des Bedarfs an der Verteilung von georeferenzierten Informationen beim LWL: Weckung des Bedarfs an der Verteilung von georeferenzierten Informationen beim

Mehr

SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse

SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse Fakultät Informatik Institut für Systemarchitektur Professur für Rechnernetze SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse Versuchsvorgaben (Aufgabenstellung) Der neu zu gestaltende Versuch

Mehr

FileMaker Pro 14. Verwenden einer Remotedesktopverbindung mit FileMaker Pro 14

FileMaker Pro 14. Verwenden einer Remotedesktopverbindung mit FileMaker Pro 14 FileMaker Pro 14 Verwenden einer Remotedesktopverbindung mit FileMaker Pro 14 2007-2015 FileMaker, Inc. Alle Rechte vorbehalten. FileMaker, Inc. 5201 Patrick Henry Drive Santa Clara, California 95054,

Mehr

Byte-Taxi. Bedienungsanleitung. Seite 1 von 8

Byte-Taxi. Bedienungsanleitung. Seite 1 von 8 Byte-Taxi Bedienungsanleitung Seite 1 von 8 Inhaltsverzeichnis 1. Beschreibung 3 2. Systemvoraussetzungen 4 3. Installationsanleitung 5 4. Bedienung 6 5. Infos & Kontakt 8 Seite 2 von 8 1. Beschreibung

Mehr

Userhandbuch. Version B-1-0-2 M

Userhandbuch. Version B-1-0-2 M Userhandbuch Version B-1-0-2 M Inhaltsverzeichnis 1.0 Was bietet mir SERVRACK?... 3 1.1 Anmeldung... 3 1.2 Passwort vergessen?... 3 1.3 Einstellungen werden in Realtime übernommen... 4 2.0 Die SERVRACK

Mehr

VMware Workspace Portal- Benutzerhandbuch

VMware Workspace Portal- Benutzerhandbuch VMware Workspace Portal- Benutzerhandbuch Workspace Portal 2.1 Dieses Dokument unterstützt die aufgeführten Produktversionen sowie alle folgenden Versionen, bis das Dokument durch eine neue Auflage ersetzt

Mehr

Univention Corporate Client. Quickstart Guide für Univention Corporate Client

Univention Corporate Client. Quickstart Guide für Univention Corporate Client Univention Corporate Client Quickstart Guide für Univention Corporate Client 2 Inhaltsverzeichnis 1. Einleitung... 4 2. Voraussetzungen... 5 3. Installation des UCS-Systems... 6 4. Inbetriebnahme des Thin

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Internet-basierendes Autorensystem zur Erschließung historischen Kulturguts. Thorsten Ludewig. Juni 2004

Internet-basierendes Autorensystem zur Erschließung historischen Kulturguts. Thorsten Ludewig. Juni 2004 METEOR Internet-basierendes Autorensystem zur Erschließung historischen Kulturguts Thorsten Ludewig Juni 2004 1 Übersicht Was ist METEOR Architektur Technische Realisierung Zusammenfassung Zukünftige Entwicklungen

Mehr

TimePunch SQL Server Datenbank Setup

TimePunch SQL Server Datenbank Setup TimePunch TimePunch SQL Server Datenbank Setup Benutzerhandbuch 26.11.2013 TimePunch KG, Wormser Str. 37, 68642 Bürstadt Dokumenten Information: Dokumenten-Name Benutzerhandbuch, TimePunch SQL Server Datenbank

Mehr

Diese Anleitung bezieht sich auf FixFoto, V 3.40. In älteren oder neueren Versionen könnte die Arbeitsweise anders sein.

Diese Anleitung bezieht sich auf FixFoto, V 3.40. In älteren oder neueren Versionen könnte die Arbeitsweise anders sein. Pfade einstellen Stand: Dezember 2012 Diese Anleitung bezieht sich auf FixFoto, V 3.40. In älteren oder neueren Versionen könnte die Arbeitsweise anders sein. Diese Anleitung soll zeigen, wie man Pfad-Favoriten

Mehr