Virtueller Rundgang durch den Pavillon des Solar Decathlon. Christian Di Battista, Patrick Gloor. BDA Bericht

Transkript

1 Virtueller Rundgang durch den Pavillon des Solar Decathlon Christian Di Battista, Patrick Gloor BDA Bericht

2

3 Dokumentenübersicht Bericht Einleitung, Eingesetzte Technologie, Evaluation 3D Engines, UDK Unreal Engine 3, Umsetzung Virtueller Rundgang, Fazit und Ausblick, Lessons Learned, Schlusswort, Danksagung Projektmanagement Einleitung, Projektübersicht, Planung, Arbeitsaufwand, Meilensteinberichte, Risikoanalyse, Anforderungen, Use Cases Systemspezifikation Softwarearchitektur, Schnittstellen, Designentscheide, Testfälle, Testprotokoll

4 Selbstständigkeitserklärung Hiermit erklären wir, dass wir die vorliegende Arbeit selbstständig angefertigt und keine anderen als die angegebenen Hilfsmittel verwendet haben. Sämtliche verwendeten Textausschnitte, Zitate oder Inhalte anderer Verfasser wurden ausdrücklich als solche gekennzeichnet. Horw, 6. Juni 2014 Patrick Gloor Christian Di Battista

5 Virtueller Rundgang durch den Pavillon des Solar Decathlon Christian Di Battista, Patrick Gloor BDA Bericht 14

6 Projekt Dokument Virtueller Rundgang durch den Pavillon des Solar Decathlon BDA Bericht Version 1.4 Schule Modul Hochschule Luzern, Technik & Architektur BDA Gloor Patrick ICT Business Solutions Finkenweg Unterkulm Tel patrick.gloor@stud.hslu.ch Di Battista Christian Software Systems Hünenbergerstrasse Cham Tel christian.dibattista@stud.hslu.ch Auftraggeber Dozenten Hüsler René Diehl Roger Letze Änderungen Freitag, 06. Juni 2014 Änderungsprotokoll Version Datum Änderung Verantwortlich Vorlage erstellt tagloor Evaluation tagloor Engine Übersicht tagloor UDK Übersicht hinzugefügt tadibat Anpassungen Umsetzung tagloor Dokumentstrukturen vervollständigt tagloor Abstract eingefügt tagloor Korrekturen tadibatt Korrekturen tadibatt Korrekturen tagloor Christian Di Battista, Patrick Gloor Seite

7 Abstract Deutsch Im Oktober 2014 ist der Kanton Luzern als Ehrengast bei der Schweizer Landwirtschaftsausstellung OLMA eingeladen, im Rahmen dieser Ausstellung wird sich der Kanton unter anderem als fortschrittliche, innovative Ausbildungsstätte präsentieren. Dabei wird das interdisziplinäre Projekt Your+, welches das Thema Gebäude als System hat, besonders präsentiert werden. Im Rahmen des Your+ Projektes wurde ein Gebäude Protoyp für den Solar Decathlon Wettbewerb 2014 in Versailles konzipiert und erbaut. Auf dem Messestand an der OLMA 2014, soll das Gebäude in der Form eines interaktiven, virtuellen Rundganges präsentiert werden. Die vorliegende Bachelor Diplom Arbeit, befasst sich mit der Planung und Realisation des virtuellen Rundganges für den Pavillon des Solar Decathlon Projektes Your+. Um eine visuell hochwertige Präsentation zu garantieren wurde eine spezielle Technologie ausgewählt. UDK ein spezielles Framework, zum Erstellen von virtuellen Welten, der Firma Epic Games. Der Rundgang wurde so konzipiert, dass sich sämtliche Funktionen einfach via Touchscreen bedienen lassen. Der Benutzer wird während des Rundganges durch eine virtuelle Projektion des Solar Decathlon Pavillon geführt. Während der Rundgang automatisiert abläuft, hat der Besucher die Möglichkeit Angaben zu seinem eigenen Energieverbrauch zu machen und erhält am Ende eine Auswertung sowie ein Vergleich mit dem Pavillon. In der vorliegenden Dokumentation wurde die verwendete Technologie zur Erstellung, sowie der Lösungsweg umfangreich dokumentiert. Dabei wurde besonderen Wert darauf gelegt, dass die Arbeit auch für zukünftige Projekte weiterverwendet werden kann. Das Endprodukt dieser Arbeit ist ein funktionierender, interaktiver und ansprechender virtueller Rundgang durch den Pavillon des Solar Decathlon. Christian Di Battista, Patrick Gloor Seite

8 English The Canton of Lucerne has been invited to take part at the Swiss agricultural exhibition OLMA as guest of honor in October The Canton will represent itself as a modern and innovative educational location. During this exhibition, there will be a special focus on the project Your+ which represents the topic, buildings as a system. As part of the Your+ project, a building prototype was designed and constructed to be presented during the Solar Decathlon Europe Competition During the OLMA exhibition, the building will be presented in the form of an interactive, virtual tour. This bachelor thesis deals with the planning and realization of the virtual tour through the Solar Decathlon pavilion. To guarantee high visual quality a special technology was selected. UDK is a special framework to create virtual worlds, manufactured by the US Company Epic Games. The tour is designed to be controlled by a simple touchscreen monitor. During the tour, the user is guided through a virtual projection of the Solar Decathlon Pavilion. While the tour is running autonomous, the user has the opportunity to provide information about his energy consumption, at the end of the tour he will receive an evaluation of his input and his results will be compared with the pavilion. In this documentation, the technology used to create the tour, as well as the approach to get to the result, has been extensively documented. A special focus has been set to ensure that the work can be used for future projects. The final product of this work is a working, interactive and appealing virtual tour of the Solar Decathlon Pavilion. Christian Di Battista, Patrick Gloor Seite

9 Inhalt 1 Einleitung Ausgangslage Ziele des Projektes Auflagen Eingesetzte Technologie Unterschied 3D Engine und Game Engine Geschichte Game Engines Wichtige Begriffe Game Engines Grafik Engine Shaders Texture Mapping Bump Mapping Grafik Engine Vergleich Übersicht 3D Engines Unity 3D CryEngine OpenWonderland UDK / Unreal Engine Blender SourceEngine Irrlicht Evaluation 3D Engines Evaluations Vorgehen Evaluationskriterien Evaluationstabelle Evaluations Resultat UDK Unreal Engine Unreal Engine 3 Einführung UDK Hardwareanforderungen UDK Editor Content Browser Material Editor Kismet Matinee Umsetzung Virtueller Rundgang Christian Di Battista, Patrick Gloor Seite

10 5.1 Übersicht Vorgehen D Modell Import in Maya Modell reduzieren Kollisionsmodell UV Maps Export Probleme und Fazit Interaktionen Ziel Vorgehen Berechnung Energieverbrauch Implementation D Umgebung Generieren der Landschaft Height- und Weightmaps Landschaft Material UDK Landschaft Probleme und Fazit Materialien Texturen importieren Materialien Erstellen Probleme und Fazit Fazit und Ausblick Aufgetretene Probleme Ausblick Mögliche Erweiterungen Lessons Learned Schlusswort Persönliches Fazit Patrick Gloor Persönliches Fazit Christian Di Battista Danksagung Quellen Christian Di Battista, Patrick Gloor Seite

11 Abbildungsverzeichnis Abbildung 1 BDA Übersicht Abbildung 2 Game Engine schematische Darstellung Abbildung 3 Pacman Arcade Automat von 1980 (Walyou, 2014) Abbildung 4 Doom (ID Games, 1993) Abbildung 5 Einfacher Mesh (Mobilefish, 2014) Abbildung 6 Scene Graph Abbildung 7 Shader Pipeline Abbildung 8 Einfaches Beispiel von Texture Mapping, Links die Texture map, Rechts angewendet auf den sichtbaren Teil des 3D-Objektes Abbildung 9 UV Map eines einfachen Rechteckes im 3D Modellierungsprogramm Autodesk Maya Abbildung 10 Links ohne Bump Mapping, Rechts mit Abbildung 11 Unity 3D (phys.ethz.ch, 2014) Abbildung 12 CryEngine 3 (images.gamersyde.com, 2014) Abbildung 13 OpenWonderland (jpirker.com, 2014) Abbildung 14 Unreal Engine 3.5 (uploads.siteduzero.com, 2014) Abbildung 15 Blender Game Engine (blender.org, 2014) Abbildung 16 Source Engine Abbildung 17 Irrlicht Engine (arteria-gaming.net, 2014) Abbildung 18 Vereinfachter Unreal Engine Workflow (udn.epicgames.com, 2012) Abbildung 19 Überblick UDK Editor Abbildung 20 Content Browser Übersicht Abbildung 21 Material Editor Übersicht Abbildung 22 Kismet Editor Übersicht Abbildung 23 Matinee Übersicht Abbildung 24 Überblick UDK und Umgebung Abbildung 25 Vorgehen Umsetzung virtueller Rundgang Abbildung 26 3D Modell Workflow Abbildung 27 Unbearbeiteter Prototyp Abbildung 28 Modell vor der Reduzierung der Polygonen Abbildung 29 Modell nach der Reduzierung der Polygonen Abbildung 30 Kollision Layers in Maya Abbildung 31 UV Maps des Modells Abbildung 32 FBX Export Einstellungen Abbildung 33 Workflow Interaktionen vom der Flash Animation bis zur UDK Integration Abbildung 34 Screenshot Interaktion Abbildung 35 Darstellung Ergebnis (Bsp. Resultat Klasse A) Abbildung 36 Workflow Umgebung Abbildung 37 TerreSculptor Landschaftsgenerator Abbildung 38 Einfach Heightmap Abbildung 39 Einfache Weightmap in TerreSculptor Abbildung 40 Landschaftsmaterial in UDK Abbildung 41 Landscape Tool UDK Abbildung 42 Workflow Materials Abbildung 43 Material mit Attributen für transparente Glasoberflächen Christian Di Battista, Patrick Gloor Seite

12 Tabellenverzeichnis Tabelle 1 Begriffe und Abkürzungen... 9 Tabelle 2 Wichtigste Komponenten Game Engine (Game Engine Architecture, 2009) Tabelle 3 3D Elemente eines Mesh Tabelle 4 Shader Typen (wikipedia.org, 2014) Tabelle 5 Normalmap einer Steinmauertextur Tabelle 6 Vergleich Game Engines Tabelle 7 Engine Evaluationskriterien Tabelle 8 Evaluation 3D Engine Tabelle 9 UDK Hardwareanforderungen (udn.epicgames.com, 2012) Tabelle 10 Probleme 3D Modelling Tabelle 11: Basiswerte des typischen Haushalt 2013 (energieeffizienz.ch, 2013) Tabelle 12 Typischer Schweizer Heizölverbrauch (WWF Schweiz, 2014) Tabelle 13: Zuordnung zu Energieeffizienz-Klassen (Prozent des Energieverbrauchs im Vergleich mit dem Schweizer Durchschnitt Tabelle 14 Probleme 3D Umgebung Tabelle 15 Probleme Materialien Tabelle 16 Allgemeine Probleme Christian Di Battista, Patrick Gloor Seite

13 Begriffe und Abkürzungen Begriff Adobe Flash Adobe Photoshop AS3 Autocad DWG Erklärung ist eine Plattform zur Programmierung und Darstellung multimedialer und interaktiver Inhalte von Adobe (proprietär) Bildbearbeitungsprogramm von Adobe Actionscript Version 3 ist eine Programmiersprache von Adobe für Programme die mit Adobe Flash / AIR / Flex erstellt werden AutoCAD ist ein CAD Programm von Autodesk Fileformat von AutoCAD Maya Maya ist ein Computerprogramm zur 3D- Visualisierung und -Animation OLMA Scaleform GFx Textur UDK UV Map XML Tabelle 1 Begriffe und Abkürzungen Alljährliche Schweizer Landwirtschaftsausstellung ist eine Vektorgrafik basierte Rendering Engine von Autodesk um Adobe Flash basierte Inhalte darzustellen Bild oder Zeichnung welche auf 3D Oberflächen angewendet wird Unreal Development Kit (Entwicklungsumgebung) Map für Texturen im UV Koordinatensystem extensible Markup Language Christian Di Battista, Patrick Gloor Seite

14 1 Einleitung Im Juni 2014 findet im französischen Versailles der internationale Wettbewerb Solar Decathlon Europe 2014 statt, die Hochschule Luzern nimmt mit dem innovativen Konzept Your+ -Teilen und Tauschen an dem Wettbewerb teil. Bei dem Solar Decathlon Wettbewerb, geht es darum, ein Haus zu entwerfen und zu bauen, dessen Energiebedarf alleine durch Sonnenenergie gedeckt wird. Vom Oktober 2014 wird die Hochschule Luzern als Gastkanton an der OLMA teilnehmen, dabei soll der Kanton Luzern, unter anderem als innovativer Standort gezeigt werden. Da sich die Hochschule Luzern mit einer Fläche von 25-30m² begnügen muss, kann der originale Pavillon natürlich nicht vor Ort aufgebaut werden. Aus diesem Grund hat die Hochschule beschlossen, eine virtuelle tour durch den Pavillon in Auftrag zu geben, neben der visuellen Präsentation des Gebäudes soll dem Besucher auch die Möglichkeit gegeben mit der virtuellen Tour zu interagieren. Diese Aufgabe wird im Rahmen einer Bachelor Diplomarbeit von Christian Di Battista und Patrick Gloor durchgeführt. 1.1 Ausgangslage Das vorliegende Projekt, ist eine Arbeit an welcher mehrere Interessegruppen beteiligt sind. Zum einen ist dies der Auftraggeber, die Hochschule Luzern. Zum anderen die Marketing Abteilung der Hochschule, welche für den Messestand an der OLMA verantwortlich ist. Das Your+ Projektteam, welches für die Realisation des Pavillons verantwortlich ist. Bei so vielen interessegruppen, ist eine gute Planung sehr wichtig, noch wichtiger ist aber eine sehr gute Kommunikation. Man wird nicht die Erwartungen aller Parteien erfüllen können, aber durch gute, proaktive Kommunikation, lassen sich viele Missverständnisse vermeiden und es kann gemeinsam ein optimaler Weg bestimmt werden. In der Nachfolgenden Grafik, wird die Ausgangslage dieser Bachelor Diplom Arbeit noch ein Mal visualisiert. Die Bachelor Arbeit wird dabei als Bindeglied zwischen dem Your+ Team und der Ausstellung an der OLMA 2014 verstanden. Christian Di Battista, Patrick Gloor Seite

15 Solar Decathlon Project Your+ OLMA 2014 Facts Facts Der Solar Decathlon ist ein anspruchsvoller, internationaler Wettbewerb im Bereich nachhaltiges Bauen Der Solar Decathlon Europe 2014 findet vom 26. Juni bis in Versailles (FR) statt Your+ Schweizer Vertreter ( Bachelor Thesis «Virtueller Rundgang durch den Pavillon des Solardecathlon» Facts Bindeglied Your+ und OLMA Echtzeit Visualisierung unter Einsatz von UDK ( Benutzer Interaktionen zur Berechnung des Energieverbrauchs Facts Findet vom Oktober in St. Gallen statt Ist eine Schweizer Landwirtschaftsmesse welche seit 1943 jährlich durchgeführt wird 2014 ist der Kanton Luzern Ehrengast Hochschule Luzern, 25-30m2 zur Verfügung Präsentation als interdisziplinärer Innovationsstandort Abbildung 1 BDA Übersicht Christian Di Battista, Patrick Gloor Seite

16 1.2 Ziele des Projektes Das Ziel der Arbeit ist die Erstellung eines attraktiven und funktionierenden virtuellen Rundganges durch den Pavillon des Solar Decathlon. Der Rundgang soll das Your+ Gebäude vorstellen und dabei dem Benutzer des Rundganges gewisse Interaktionen ermöglichen. Diese Interaktionen sollen im Zusammenhang mit den Themen Energie, Energieverbrauch, Gebäude als System oder ähnlichen Begriffen stehen. Für die technische Umsetzung soll eine geeignete Technologie evaluiert werden, auch für die Steuerung der Interaktionen sollen geeignete Systeme evaluiert werden. Die Umsetzung soll dabei möglichst genau Dokumentiert werden, insbesondere soll sichergestellt werden, dass die Arbeit auch für zukünftige Projekte weiterverwendet werden kann. 1.3 Auflagen Da das finale Produkt an der OLMA präsentiert wird und dabei die Hochschule Luzern vertritt, hat das Marketing Komitee einige Einschränkungen bekannt gegeben. Der Rundgang soll keinerlei Spielereien wie zum Beispiel unscharfe oder hüpfende Bilder enthalten, die Interaktionszeit soll maximal drei Minuten betragen. Die Corporate Identity der Hochschule Luzern muss für das Design der Interaktionen beachtet werden, das Corporate Design des Your+ Teams sollte ebenfalls Einzug in das Projekt finden. Das Logo der Hochschule Luzern soll während des gesamten Rundganges oben Links angezeigt werden. Der Rundgang soll nicht durch einen Abspann beendet werden. Christian Di Battista, Patrick Gloor Seite

17 2 Eingesetzte Technologie In diesem Kapitel wird das Thema 3D Engines oder umrissen und es wird vor allem auf sogenannte Game Engines eingegangen. Unter anderem wird der Unterschied zwischen reinen Grafik Engines und Game Engines aufgezeigt sowie ein kleiner Überblick zu bekannten Game Engines gegeben. 2.1 Unterschied 3D Engine und Game Engine Spricht man in der heutigen Zeit von einer Grafik Engine, so meint man oft eine Game Engine. Dabei sollte man diese beiden Begriffe voneinander unterscheiden. Untenstehende Grafik ist eine vereinfachte Darstellung aus der Definition von Jason Gregory (Game Engine Architecture, 2009) Game Skrippting Netzwerk Physik Game Engine Grafikengine Steuerung Datenmanagement Künstliche Intelligenz Sound Assets Texturen, Sounds, Musik, Materialien, Schriftarten, 3D Modelle usw. Interfaces und SDKs OpenGL, DirectX, usw. OS/Drivers Hardware Abbildung 2 Game Engine schematische Darstellung Während eine Grafik Engine verantwortlich ist, die dargestellten Objekte zu zeichnen und dabei eigentlich nur einer von vielen (wenn auch einer der wichtigsten) Bestandteile einer Game Engine ist. Um eine Grafik Engine zu erstellen wird in den meisten Fällen auf eine sogenannte API zurückgegriffen, diese APIs bieten Schnittstellen zur Grafikhardware (GPU) sehr bekannte Beispiele sind OpenGL (Plattformunabhängig) und DirectX (Microsoft Systeme). Eine Game Engine dagegen, ist ein weitaus komplexeres Gebilde und erweitert die reine Grafik Engine um weitere, wichtige Komponenten. In der Nachfolgenden Tabelle werden die wichtigsten Komponenten beschrieben, zu beachten gilt, dass bei Christian Di Battista, Patrick Gloor Seite

18 modernen Engines noch weit mehr Komponenten unterschieden werden und einzelne Kernkomponenten (z.b. die Grafikengine) noch weiter aufgeteilt werden: Komponente Scripting Netzwerk Physik Steuerung Datenmanagement Künstliche Intelligenz Sound Beschreibung Viele Game Engines liefern eine eigene Scriptsprache, mit vorgefertigten Scripts mit, mit diesen Scripts, lassen sich Inhalte viel schneller modifizieren und entwickeln. Spiele in der heutigen Zeit liefern oft einen Mehrspielermodus mit, das bedeutet, dass mehrere Spieler gleichzeitig von verschiedenen Clients aus gegen oder miteinander spielen. Aus diesem Grund sind bei modernen Game Engines die Netzwerkkomponenten meistens komplett integriert. Die Physikalischen Grundregeln sind ein wichtiger Bestandteil von modernen Game Engines. Sie bestimmen wie sich ein Objekt bei einer Kollision verhält. In modernen Game Engines wird meist mit Drittanbietern SDKs gearbeitet, zum Beispiel Havok Physik Engine oder PhysX. Jedes Spiel muss Benutzereingaben verarbeiten können, dies wird vom Steuerungsmodul verwaltet. Diese Komponente ist eigentlich in jeder Game Engine vorhanden, sie regelt den Zugriff auf Ressourcen wie zum Beispiel Texturen, Sounds, Modelle usw. Einige Engines machen dies zum Beispiel mit eigenen Paket Strukturen sogenannten Packages. Die KI hat sich im Laufe der Jahre zu einem enorm wichtigen Bestandteil von Game Engines entwickelt. Wurde dies am Anfang oft noch Spielespezifisch entwickelt, erkannte man sehr schnell wiederkehrende Muster und hat daraufhin angefangen die KI Grundlagen in die Game Engine zu implementieren Diese Komponente ist hauptsächlich für die Handhabung von Sound- und Musikeffekten verantwortlich, auch hier wird heute oft auf Drittanbieter SDKs zurückgegriffen. Tabelle 2 Wichtigste Komponenten Game Engine (Game Engine Architecture, 2009) Zusätzlich zu der Game Engine, gibt es noch weitere Komponenten welche mit einem Vollständigen Spiel zusammenarbeiten. Dies umfasst die Assets, diese halten wichtige, wiederverwendbare Komponenten wie etwa, Texturen, Musik oder 3D - Modelle. Ein weiterer wichtiger Teil sind die Middlewares, diese dienen den Programmierern als Templates für wichtige Funktionen, zum Beispiel die Ansteuerung der 3D Hardware, bekannte Vertreter dieser Middlewares sind DirectX und OpenGL. Christian Di Battista, Patrick Gloor Seite

19 Diese APIs stellen wiederverwendbare Funktionen zur Verfügung, damit der Programmierer diese nicht bei jeder Engine neu schreiben muss. Solche APIs existieren aber nicht nur für die Grafik, sondern auch für Sound, Input, Hardware Physics usw. Christian Di Battista, Patrick Gloor Seite

20 2.2 Geschichte Game Engines Bevor die ersten richtigen Game Engines auftauchten, wurden Spiele nicht Modular geschrieben sondern alles wurde explizit auf das Spiel zugeschnitten, die beinhaltete auch die Grafik Engine. In den 1980ern wurde die Spielewelt durch die Arcade Automaten dominiert. (wikipedia.org, 2014) Abbildung 3 Pacman Arcade Automat von 1980 (Walyou, 2014) Erst in den 1990er wurde der Begriff Game Engine das erste Mal verwendet, mit dem Erscheinen des bekannten Spiels Doom von ID Software, wurde erstmals ein Spiel ausgeliefert, welches eine klare Aufteilung in verschiedene Teilmodule aufwies. Die Assets (Texturen, Sounds, Musik usw.) waren klar von den Spielespezifischen Teilen getrennt. Mit dem Erscheinen dieser Game Engines, wurden auch erstmals Spiele auf Basis von solchen Engines programmiert. Der Vorteil solcher Lizenzierungsmodelle war, dass ein Spiel nicht mehr von Grund auf neu programmiert werden musste und sich ein Hersteller auf den Kern eines Spieles konzentrieren konnte. Abbildung 4 Doom (ID Games, 1993) Spätere Game Engines wie zum Beispiel Epics Unreal Engine von 1998 oder IDs Quake 3 Engine wurden speziell mit dem Hintergedanken der Lizenzierung Programmiert, da sich dieses Modell als Christian Di Battista, Patrick Gloor Seite

21 zuverlässige Einnahmequelle herausstellte. Durch die immer besser werdenden Entwicklungstools der Game Engines, wurde das reine Programmieren immer mehr durch Design Schritte ergänzt. In modernen Entwicklungen sind meiste mehr Designer als Programmierer involviert. Heute läuft die Weiterentwicklung der Engines vor allem in Richtung neue Hardwareplattformen, allen voraus Mobile Plattformen wie Android oder ios. Engines wie Unity oder Unreal Engine haben diesen Trend bereits früh erkannt und bieten bereits heute ein umfangreiches Toolset für Mobile Plattformen an. Eine weitere Entwicklung welche zu beobachten ist, immer mehr Engines werden in Hochsprachen wie C# oder Java entwickelt. Der Grund dafür ist, dass die Perfomanceeinbussen solcher Sprachen mit der heutigen Hardware so gut wie nicht mehr messbar sind. 2.3 Wichtige Begriffe Game Engines In diesem Abschnitt, werden die wichtigsten Begriffe im Zusammenhang mit Game- und Grafikengines erklärt. Diese sind wichtig für das Verständnis der Arbeit Grafik Engine Wir haben im vorherigen Abschnitt gehört, was der Unterschied zwischen Grafik Engine und Game Engine ist. In diesem Abschnitt, wird erklärt wie die meisten heutigen Grafik Engines funktionieren, also wie das Bild auf den Bildschirm kommt. Noch immer, setzt ein Grossteil der heutigen Grafikengines auf sogenannte Polygongrafik, das heisst, dass die dargestellten Bilder aus vielen einzelnen Polygonen (Vieleck) zusammengesetzt sind. Diese Polygonen nennt man auch Primitives (Ebenfalls zu den Primitives gehören Linien und Punkte). In den meisten heutigen APIs (DirectX, OpenGL) ist fest vorgeschrieben wie solche Polygone aussehen dürfen, es werden nämlich nur maximal drei Ecken zugelassen. Werden nun viele einzelne solcher Vielecke zu einem Objekt zusammengefügt, so nennt man dieses Drahtgittermodell, Mesh. Die Meshes sind die Objekte die dann später auf dem Bildschirm gerendert werden. Christian Di Battista, Patrick Gloor Seite

22 Abbildung 5 Einfacher Mesh (Mobilefish, 2014) Element Vertex Face Beschreibung Eckpunkte von Meshes welche Informationen wie zum Beispiel Texturkoordinaten und Objektkoordinaten enthalten können Ein Face ist die flache Oberfläche eines 2D oder 3D Objektes Edge Polygon Tabelle 3 3D Elemente eines Mesh Eine Edge, sind die Linien welche verschiedene Faces voneinander trennt Sind die Primitives eines Meshes, in den meisten Engines sind es Dreiecke Damit ein solcher Mesh überhaupt in 3D auf einem Bildschirm dargestellt werde kann, benötigt es eine sogenannte Projektion. Die Koordinaten (Vertices) eines jeden Polygons welches sich in der 3D Welt befindet, sind dabei im Arbeitsspeicher hinterlegt, bewegt sich nun das Objekt, oder verschiebt sich die Scene, so werden die Koordinaten entsprechen angepasst und der Renderer kann das Bild anhand der neuen Daten aktualisieren. Dies nennt man Projektion von 3D Daten auf eine 2D Oberfläche. Ein weiterer sehr wichtiger Teil von modernen Grafikengines, ist der sogenannte Scene graph, der Scene Graph organisiert die 3D Objekte welche auf dem Bildschirm dargestellt werden. Er ist eine weitere Abstraktion der RenderAPIs (OpenGL, DirectX usw.). Bevor die Scene Graphen eingesetzt wurden, musste jedes Objekt auf dem Bildschirm, einzeln verwaltet werden. Die Scene Graphen organisieren alle Geometrie Objekte auf dem Bildschirm hierarchisch, dies erlaubt schnellere und einfachere Anpassungen einer Szene, in Abbildung 6 Scene Graph wird der Aufbau nochmals dargestellt. (techsoft3d, 2014) Christian Di Battista, Patrick Gloor Seite

23 Scene Graph OpenGL DirectX Grafikkarte Output Device Abbildung 6 Scene Graph Shaders Shading Einheiten (Shading ist Englisch und steht für Schattierung) existieren sowohl in Software- als auch in Hardwareform. Anfangs war ihre Aufgabe, wie der Name schon sagt, lediglich Schatteneffekte zu erzeugen. In der heutigen Zeit werden sie aber auch für weit mehr 3D Effekte verwendet (Siehe Tabelle 4 Shader Typen ). Der Begriff Shader (im Zusammenhang mit Computer 3D Technik) wurde das erste Mal von der Firma PIXAR im Jahre 1988 verwendet. Mit dem Erscheinen von immer moderneren Grafikkarten wurden Shaders auch von den gängigen APIs (DirectX und OpenGL) unterstützt. Moderne Shadertypen sind in der Lage Effekte zu berechnen welche früher nur auf dem CPU möglich waren und dies meist auch um einiges schneller. Moderne Grafikkarten besitzen mehrere Tausend Shader Einheiten (z.b. NVIDIA GTX 780) welche parallel angesteuert werden können. Shaders kommen zum Einsatz nachdem die Primitives (Polygonen, Punkte oder Linien) bereits erzeugt wurden, oft wird in diesem Kontext auch von Postprocessing gesprochen. Vertex Shaders Tesselation Shaders Geometry Shaders Pixel Shaders Abbildung 7 Shader Pipeline Christian Di Battista, Patrick Gloor Seite

24 Anfangs existierten lediglich die Pixelshader (oder auch Fragmentshader) welche die Farbe von einzelnen Pixeln verändern konnten. Mit der Zeit wurden immer mehr Shadertypen hinzugefügt, damit die Effekte möglichst optimal ausgeführt werden können, existiert eine sogenannte Shader Pipeline (Abbildung 7 Shader Pipeline). Shadertyp Vertex Shaders Tesselation Shaders Geometry Shaders Pixel Shaders Beschreibung Vertex Shader werden für jedes Vertex angewendet, welche der Grafikhardware übergeben werden. Dabei kann der Vertex Shader die Werte (und nur die Werte) der Vertices ändern zum Beispiel: Position, Farben, Texturen, Beleuchtung. Dadurch können in Echtzeit realistische Effekte wie Licht und Schatten dargestellt werden. Eingeführt mit DirectX11 und OpenGL 4.0, die Tesselation Shaders können zur Laufzeit einfache Meshes in zusätzliche Meshes unterteilen und dadurch den Detailgrad von Objekten um ein vielfaches verbessern. Dabei kann der Shadereffekt so konfiguriert werden, dass der Detaillevel (auch LOD genannt) grösser wird, je näher man dem Objekt ist. Geometry Shaders wurden erst mit DirectX 10 und OpenGL 3.2 eingeführt, im Gegensatz zu den anderen Shadern können die Geometry Shaders ganze Primitives (Polygon, Linie oder Punkt) verändern, erstellen oder zerstören. Heute wird er vor allem für Partikeleffekte eingesetzt. (informit, 2014) Pixel Shaders, auch bekannt als Fragment Shaders, verändern einzelne Fragmente (Pixel) von zu rendernden Elementen, dies ermöglicht zum Beispiel realistischere Darstellung von Oberflächen oder Materialien, häufig werden sie für Spiegelungen, Blendeffekte oder Schatten eingesetzt. Tabelle 4 Shader Typen (wikipedia.org, 2014) Christian Di Battista, Patrick Gloor Seite

25 2.3.3 Texture Mapping Als Texture Mapping bezeichnet man den Ablauf, in der 3D Computertechnik, ein 3D Objekt mit zweidimensionalen Obeflächen sogenannten Texturen auszustatten. Es wurde 1974 von Edwin Catmull erstmals beschrieben. (wikipedia.org, 2014) Abbildung 8 Einfaches Beispiel von Texture Mapping, Links die Texture map, Rechts angewendet auf den sichtbaren Teil des 3D-Objektes Jedes Vertex in der 3D Computer Welt hat eine sogenannte Textur Koordinate, in der 2D Welt werden dies oft als UV Koordinaten bezeichnet. Mithilfe dieser Koordinaten wird dann eine Sogenannte Textur Karte erstellt, dies ist eigentlich nichts anderes als wenn man zum Beispiel eine Kartonschachtel auseinander baut und flach auslegt. Die einzelnen Flächen werden auch Faces genannt, auf diese wird dann die Textur angewendet. Heute gibt es viele verschieden mathematische Methoden um eine Textur auf eine Oberfläche anzuwenden, dies ist nötig, weil die 3D Modelle immer komplizierter und detaillierter werden (eine 2d Textur auf eine Kugel anzuwenden ist um einiges komplizierter als auf ein Quadrat). Moderne 3D Modellierungsprogramme bieten die Möglichkeit UV Maps automatisch zu erstellen, oft muss aber immer noch von Hand nachgebessert werden um das optimale Resultat zu erhalten. Abbildung 9 UV Map eines einfachen Rechteckes im 3D Modellierungsprogramm Autodesk Maya 2015 Christian Di Battista, Patrick Gloor Seite

26 2.3.4 Bump Mapping Bumpmapping ist ein Verfahren in der 3D Computertechnik, um zweidimensionale Oberflächen plastisch wirken zu lassen. Wichtig ist, dass bei diesem Verfahren die Geometrie des Objektes nicht verändert wird. Es werden lediglich Beleuchtung und Schattierung der Textur verändert. Abbildung 10 Links ohne Bump Mapping, Rechts mit Heute geschieht dies fast ausschliesslich in Zusammenarbeit mit Shadern (in diesem Falle meist Pixelshader). Die Informationen zum Erzeugen der Bumpmaps sind in einem Texturfile hinterlegt, der sogenannten Normalmap. (en.wikipedia.org, 2014). Eine Normalmap, beinhaltet im Gegensatz zu normalen Texturen nur die Farben Rot, Blau und Grün, jedoch kein Schwarz und kein Weiss. Diese drei Farben lassen sich dann auf die drei Achsen X, Y und Z übersetzen und gibt der Grafikengine dadurch die Möglichkeit einen Bumpmapping Effekt darzustellen. (gamedevelopment.tutsplus.com, 2014) Tabelle 5 Normalmap einer Steinmauertextur Christian Di Battista, Patrick Gloor Seite

27 2.4 Grafik Engine Vergleich Engine Grafische Qualität Plattformen Unity Hoch Windows/OS X/Linux/Xbox 360/Xbox One/Wii/Wii U/PlayStation 3/PlayStation 4/PlayStation Vita/Windows Phone/iOS/Android CryEngine Extrem hoch Windows/Linux Xbox 360/Xbox One/PlayStation 3/iOS Aktuelle Grafik Engine Version Beispiel Applikationen Unity 4.5, Mai 2014 Cities in Motion 2 Deus Ex: The Fall CryEngine 3.6.2, Mai 2014 Crysis 3 Aion OpenWonderland Niedrig Plattformunabhängig JMonkey 2.0, 2008 Collaborative Welten OpenSource UDK / Unreal Engine 3 Sehr hoch Windows/OS X/Linux/ Xbox 360/ PlayStation 3/ /ios/android Blender Mittel GNU/Linux, Mac OS X, Microsoft Windows und FreeBSD Source Engine Mittel Windows/OS X/Linux Xbox 360/Xbox One PlayStation 3 Android Unreal Engine 3.5, Februar 2014 Blender 2.70a, April 2014 Source Engine v5402, 2013 Unreal Tournament 3 Tank Wars Color Cube Half-Life 2 Counterstrike: Source Preis Free für Nicht-Kommerzielle Zwecke Free für Nicht-Kommerzielle Zwecke Free für Nicht-Kommerzielle Zwecke OpenSource Ab 1000$ Irrlicht Mittel-hoch Plattformunabhängig Irrlicht v1.8.1, Dezember 2013 Super TuxKart OpenSource Tabelle 6 Vergleich Game Engines Christian Di Battista, Patrick Gloor Seite

28 2.5 Übersicht 3D Engines Im folgenden Abschnitt, werden die am meisten verbreiteten Game Engines kurz beschrieben. Open- Wonderland wurde speziell ausgewählt, da es in der anfänglichen Aufgabenstellung erwähnt wurde und an der Hochschule Luzern schon mehrere Projekte damit verwirklicht wurden Unity 3D Unity 3D, vom Entwickler Unity Technologies, ist neben der Unreal Engine eine der beliebtesten Entwicklungsplattformen für Spiele. Insbesondere die breite Unterstützung von verschiedenen Plattformen, einschliesslich den wichtigste, mobilen Plattformen, macht Unity zu einem sehr mächtigen Tool. Die aktuelle Version von Unity ist 4.3 und führte erstmals auch die Möglichkeit ein, 2D Anwendungen zu erstellen. Unity 5 ist bereits in Entwicklung. Die grafischen Eigenschaften von Unity orientieren sich an anderen gängigen Spiele Engines und unterstützen die meisten aktuellen DirectX und OpenGL Features. Der Editor von Unity orientiert sich grösstenteils an der Benutzeroberfläche moderner 3D Modellierungsprogrammen, Unity unterstütz den direkten Import fast aller gängigen 3D Modellierungsprogrammen (Maya, 3D Studio Max, Blender usw.). Leider birgt der Editor einige Schwächen im Vergleich zur Konkurrenz, so ist es zum Beispiel nicht möglich die Importierten Objekte weiter zu bearbeiten, auch andere wichtige Editor Tools fehlen Unity und es muss für viele Arbeitsschritte auf Drittanbieter Software zurückgegriffen werden. Das Lizenzierungsmodell von Unity ist ein sogenanntes Freemium Modell, die Basis Version ist kostenlos, währen die Pro- Version kostet und einige wichtige zusätzliche Features mit sich bringt. Abbildung 11 Unity 3D (phys.ethz.ch, 2014) Christian Di Battista, Patrick Gloor Seite

29 2.5.2 CryEngine Fotorealismus in Spielen, ist ein Ziel auf das viele Hersteller hin arbeiten. Doch keiner kam diesem Ziel je so nahe wie die Firma Crytek mit ihrer CryEngine. Bereits die CryEngine 2.0 war in der Lage extrem realistische Bilder zu rendern, noch heute gilt das auf der CryEngine 2.0 basierende Spiel Crysis als eines der grafisch besten Spiele. Die aktuellste Version 3.6 unterstützt verschiedene Plattformen wie Windows, Mac OSX, Linux, xbox 360, Nintendo wii U und Playstation 3. Mobile Plattformen werden noch nicht unterstützt, sollen aber mit dem nächsten Release ebenfalls als Plattform zur Verfügung stehen. Mit der Veröffentlichung der CryEngine 3.0 hat Crytek erstmals auch eine freie Version zur Verfügung gestellt, welche zum Entwickeln von gratis Spielen und Anwendungen benutzt werden darf. Der Editor ist einer der Fortschrittlichsten der Branche und konkurriert direkt mit UDK, der CryEngine Editor funktioniert einzigartig, da er es erlaubt mit nur einem Mausklick direkt in die aktuelle Szene zu springen, ohne das Spiel neu zu kompilieren. Der grosse Nachteil der CryEngine ist der hohe Hardwarehunger, im Vergleich zu den Konkurrenten braucht die CryEngine weitaus stärkere Systeme um eine saubere Darstellung zu ermöglichen. Das Lizenzmodell der kostenpflichtigen Version ist ähnlich wie bei UDK. Abbildung 12 CryEngine 3 (images.gamersyde.com, 2014) OpenWonderland Open Wonderland ging Ursprünglich von Sun Microsystems Projekt Wonderland aus. OpenWonderland ist keine Game Engine im herkömmlichen Sinne, es wurde hauptsächlich für grosse online Welten konzipiert in welchem Menschen miteinander interagieren könne, ähnlich wie das bekannte Programm Second Life( Das Ziel von OpenWonderland ist es eine stabile, skalier- Christian Di Battista, Patrick Gloor Seite

30 bare, verlässliche, virtuelle Plattform für Unternehmen zu schaffen um besser mit Kunden und Mitarbeiter kommunizieren zu können. OpenWonderland ist sehr modular aufgebaut und der Fokus ist nicht auf die grafische Präsentation gerichtet sondern mehr auf Funktionalitäten wie Audio/ Video Kommunikation und Sicherheit. OpenWonderland benutzt die jmonkeyengine 2.0 als Render System, dies ist eine OpenSource (BSD) Java basierte Engine. Abbildung 13 OpenWonderland (jpirker.com, 2014) UDK / Unreal Engine 3.5 Das Unreal Developement Kit, kurz UDK, ist ein Spiele Entwicklungsframework basierend auf Epic Games Unreal Engine 3. Im November 2009 (wikipedia.org) wurden mit der Veröffentlichung von UDK grosse Teile der Unreal Engine 3 frei zugänglich gemacht. Der erste Release basierte auf der Unreal Engine Version 3.5 (eine Weiterentwicklung der Unreal Engine 3). Bereits frühere Versionen der Unreal Engine (1 und 2) lieferten freie Editoren mit um Inhalte für Spiele zu kreieren. Die einfache Oberfläche des Unreal Editors wurde auch für UDK beibehalten, jedoch um eine Vielzahl an Funktionen erweitert, welche es einem nun erlauben vollumfängliche Spiele zu erstellen. Eines der wichtigsten Features der Unreal Engine 3 ist das sogenannte Unreal Lightmass dies erlaubt es, extrem komplexe, statische Beleuchtungen zu erzeugen ohne grossen Rechenaufwand. Weitere wichtige Features sind die Unterstützung von Mobile Plattformen (ios) sowie die Möglichkeit Spiele im Browser (mit HTML5 und JavaScript) laufen zu lassen (Erstmals im März 2013 vorgestellt). Im März 2014 wurde die neueste Generation der Unreal Engine vorgestellt (Unreal Engine 4) diese bietet unteranderem erweiterte Mobile und Browser Unterstützung sowie eine völlig überarbeitetet Partikel und Beleuchtungssystem. Während UDK frei erhältlich ist und erst Kosten anfallen für kommerzielle Produkte, ist Unreal Engine 4 in einem neuen, monatlichen Lizenzierungsmodell erhältlich (20$ pro Monat). Christian Di Battista, Patrick Gloor Seite

31 Abbildung 14 Unreal Engine 3.5 (uploads.siteduzero.com, 2014) Blender Blender ist eine OpenSource 3D-Modelling Software, sie wurde ursprünglich als interne Applikation bei der niederländischen Firma NeoGeo erstellt und im Jahr 2003 erstmals freiverfügbar gemacht. Blender ist vor allem durch seine 3D-Modellierungs Funktionalitäten bekannt, bietet aber auch eine sehr Leistungsfähige Game Engine sowie einen Videoschnitteditor. Die Game Engine wird für einige OpenSource Projekte verwendet, die grafische Darstellung ist sehr hochwertig, leider fehlen Blender einige wichtige Elemente um mit anderen Engines zu konkurrieren, dies Umfasst zum Beispiel ein einfaches GUI für Scripting oder Audiointegration. Blender wird aber oft als Ergänzung zu anderen Game Engines eingesetzt, vor allem aufgrund seiner überragenden 3D - Modellierungsqualitäten. Christian Di Battista, Patrick Gloor Seite

32 Abbildung 15 Blender Game Engine (blender.org, 2014) SourceEngine Die Source Engine des Herstellers Valve ist vor allem bekannt durch das Spiel Half-Life 2, die Engine wurde während 5 Jahre entwickelt. Die Engine ist teilweise noch auf der alten Quake 1 Engine basierend, eine der ersten echten Game Engines. Die Engine wird vor allem in Valve Spielen verwendet, kann jedoch lizenziert werden, leider sind keine offiziellen Preise bekannt. Das grosse Plus dieser Engine ist ihre Skalierbarkeit, sowie die Unterstützung von fast allen bekannte PC und Konsolen Plattformen. Die grafische Leistung der Source Engine kann zwar nicht mit denen der CryEngine oder der Unreal Engine verglichen werden, wird aber immer noch laufend modernisiert und kann durchaus gute Bilder erzeugen. Eine neue Version der Source Engine ist momentan in Entwicklung, die neue Version enthält unteranderem, umfangreiche Editoren zur Erstellung von eigenen Projekten. Christian Di Battista, Patrick Gloor Seite

33 Abbildung 16 Source Engine Irrlicht Die Irrlicht Engine, ist eine Open Source Game Engine. Der erste Release wurde ausschliesslich von Nikolaus Gebhardt programmiert, erst später entstand ein kleines Entwicklungsteam rund um die Engine. Die Irrlicht Engine unterstütz viele moderne Grafik Features und fast alle gängigen Formate für 3D und 2D Objekte. Der grösste Pluspunkt von Irrlicht, ist die riesige Community, dank der Tatsache, dass Irrlicht komplett OpenSource ist, existiert eine Vielzahl an Modifikationen und Zusatz Programmen. Irrlicht ist für fast alle gängigen Plattformen verfügbar, inklusive ios und Android. Abbildung 17 Irrlicht Engine (arteria-gaming.net, 2014) Christian Di Battista, Patrick Gloor Seite

34 3 Evaluation 3D Engines Damit das richtige, technische Werkzeug ausgewählt werden kann um den virtuellen Rundgang umzusetzen, benötigt es eine saubere Evaluation. Im nachfolgenden Abschnitt werden die Evaluation und deren Resultate beschrieben. 3.1 Evaluations Vorgehen Vor der eigentlichen Evaluation wurden, durch Recherchen, eine Auswahl von verschiedenen Produkten gesammelt. Produkte welche von Anfang an nicht in Frage kamen (z.b durch fehlende Entwickler Tools, zu hohe Kosten oder fehlende Community) wurden herausgefiltert. Für die Übriggebliebenen Produkte wurde eine Softwareevaluation gemacht. 3.2 Evaluationskriterien Die Kriterien wurden in einem Teammeeting erarbeitet und beschrieben. Ausserdem wurde bestimmt, welche Kriterien als sogenannte Killerkriterien gelten, dies sind Kriterien welche ein Produkt unbedingt erfüllen muss, ansonsten ist es für das Projekt nicht geeignet. Ober Kriterium Functional Fit Flexibility Support Continuity Maturity Beschreibung Stimmt das Produkt mit den technischen Anforderungen überein? In diesem Teil befinden sich wichtige Killerkriterien womit sich schnell feststellen lässt ob ein Produkt geeignet ist oder nicht. Hier handelt es sich um Kriterien, welche wichtig sind für den Verlauf der Arbeit, ist das Produkt benutzerfreundlich, kann im Falle von Problemen reagiert werden und bietet es die richtigen Schnittstellen zu anderen Systemen an? Support ist ein wichtiger Eckpfeiler eines jeden Projektes, sollten Probleme auftreten muss eine gewisse Menge an Support vorhanden sein zum Beispiel durch Dokumentationen oder Hersteller Foren Ein wichtiger Aspekt zur Auswahl des Produktes, ist dessen Aktualität, wird es ständig weiterentwickelt, ist eine aktive Community vorhanden? Hier geht es vor allem darum, wie viele Projekte bereits mit dem Produkt verwirklicht wurden und wie viel Erfahrung zum Produkt bereits im Projektteam vorhanden ist. Tabelle 7 Engine Evaluationskriterien Christian Di Battista, Patrick Gloor Seite

35 3.3 Evaluationstabelle Functional Fit Flexibility Support Continuity Maturity Architektur Visualisation Realtime Interaktionen Skritpting Optische Darstellung GUI Developement Kit Anpassungsfähigkeit (Customization) Architektur Benutzerfreundlichkeit Betriebssystem/Betriebssystem-Unabhängigkeit Schnittstellen (Import 3D-Modelle) Skalierbarkeit Dokumentation Qualität des Supports Support Infrastruktur (Hersteller oder Community-Support) Aktualisierungszyklus Grösse und Aktivität der Benutzerbasis (Community) Transparenz (Code/Interfaces, Issue-Tracking, Roadmap) Entwicklungsstatus Erfahrung im Team vorhanden Referenzprojekte Bewertung Lizenzkosten (Schätzung) KO Kriterium? Priorität 3D Engines Unity K.O. Free non-commercial CryEngine K.O. Free non-commercial OpenWonderland OpenSource UDK Free non-commercial Blender K.O. OpenSource Source Engine K.O. Ab 1000$ Irrlicht K.O. OpenSource Tabelle 8 Evaluation 3D Engine Christian Di Battista, Patrick Gloor Seite

36 3.4 Evaluations Resultat Während der Evaluation wurden die Produkte anhand von Recherchen bewertet und evaluiert. Während der Evaluation zeigte sich, dass fast alle Produkte in einem Punkt sehr stark sind während sie in anderen sehr weit abfallen. Am Schluss vielen aber alle Produkte bis auf zwei beim Killerkriterium Erfahrung im Team vorhanden raus. Dieser Punkt war für das gelingen des Projektes sehr wichtig, da wenig Zeit zur Verfügung stand. Die übriggebliebenen Produkte waren UDK von Epicgames und das Open Source Produkt OpenWonderland. OpenWonderland hat vor allem durch den offenen JAVA Quellcode überzeugt, dieser ermöglicht umfangreiche Anpassungen. Die offensichtliche Schwäche von OpenWonderland ist die jmonkey 2.0 Grafik Engine, diese ist im Vergleich zu den anderen Produkten nicht sehr leistungsstark. Gerade für die Erstellung eines virtuellen Rundganges für ein interdisziplinäres Projekt der Hochschule Luzern, ist aber, nach Ansicht des Projektteams, eine gute visuelle Darstellung sehr wichtig. UDK bietet ein überragendes, visuelles Potential welches einzig von der CryEngine noch überboten würde. UDK zeichnet sich weiter durch ein sehr einsteigerfreundliches und mächtiges Entwicklerframework aus. Ebenfalls sehr wichtig ist die umfangreiche Online Dokumentation in Form der Unreal Development Networks. Die Community ist unübertroffen in ihrer Grösse, mit UDK wurden bereits mehrere tausend Projekte verwirklicht, einzig Unity kann hier mithalten. Christian Di Battista, Patrick Gloor Seite

37 4 UDK Unreal Engine 3 Mit der Evaluation im vorhergehenden Kapitel haben wir uns für das Game Engine Framework UDK von Epic Games entschieden. In diesem Kapitel wird dessen Aufbau erklärt und die wichtigsten Funktionen vorgestellt. 4.1 Unreal Engine 3 Einführung Mit UDK und damit Unreal Engine 3, liefert Epic Games auch eine umfassende Dokumentation mit, dies beinhaltet vor allem einige wichtige Richtlinien für die Erstellung von Inhalten. In Abbildung 18 Vereinfachter Unreal Engine Workflow wird der sogenannte Design Workflow von UDK aufgezeigt. Dieses Vorgehen sollte wenn möglich immer beachtet werden. Konzept Grobkonzept des Programms Erste Prototypen mit Kismet Mesh Erstellung Modelle werden in 3D Programmen erstellt Modelle werden aus externen Quellen bezogen Modelle werden vorbereitet (Polygon Reduzierung, UV-Maps usw.) Material Erstellung Materialien werden erstellt Texturen aus externen Quellen werden bearbeitet (Normal Maps und Specular Maps werden erstellt) Level Prototyp Einfacher Prototyp des Levels wird erstellt (meist mit BSP Brushes) Erste "Rohmeshes" werden importiert Scripting Effekte, Events, Programmverhalten werden umgesetzt Level Ausarbeiten Beleuchtung, Schatten, Texturen, Materialien Skalierung der Elemente Ausgearbeitete Meshes werden verteilt (Dekoration) Performance Optimierung Memory Optimirung Beleuchtungs Optimierung Abbildung 18 Vereinfachter Unreal Engine Workflow (udn.epicgames.com, 2012) Christian Di Battista, Patrick Gloor Seite

38 4.2 UDK Hardwareanforderungen Hardware User Min. Entwickler Min. Entwickler Empf. CPU 2.0 GHz 2.0 GHz 2.0 GHz Multicore Epic Games Entwickler Dual Core Xeon 3.17 GHz Memory 2GB 2GB 8GB Ram 24 GB Grafikkarte Shader 3.0 Kompatibel Shader 3.0 Kompatibel Shader 3.0 mit min 786 MB video RAM Nvidia Geforce GTX Betriebssystem Windows XP SP3 Windows XP SP3 Windows 7 64bit Windows 7 64bit Tabelle 9 UDK Hardwareanforderungen (udn.epicgames.com, 2012) 4.3 UDK Editor Der UDK Editor ist der Einstiegspunkt zu UDK, die meisten Arbeiten für ein Projekt werden hier beginnen. Der Aufbau ist relativ simpel und man findet sich schnell zu Recht. Die Projektansicht ist in vier Fenster unterteilt (Viewports): 2D Top (von oben), 2D Side (von der Seite), 2D Front (von vorne) und die 3D Ansicht. Auf der linken Seite befindet sich die Editor Toolbar, diese stellt vor allem Werkzeuge zur Verfügung um die sogenannten BSP Brushes (Eine Form zur Erstellung von Geometrie Objekten in UDK) zu bearbeiten. In den Viewports können Objekte entweder durch Drag&Drop aus dem Content Browser erstellt werden, oder mittels Rechtsklick auf den jeweiligen Viewport. In den Viewports lassen sich die Objekte dann platzieren und skalieren. Abbildung 19 Überblick UDK Editor 1. Viewports 2. Brush BSP Tools 3. Game Engine Toolbar (Zugriff auf weitere Entwicklungstools) Christian Di Battista, Patrick Gloor Seite

39 4.4 Content Browser Um die grosse Anzahl an Assets (Materialien, Texturen, Modelle, Sounds usw.) zu verwalten, bietet UDK den sogenannten Content Browser an. Im Content Browser lassen sich neue Elemente importieren, verändern oder gar direkt erstellen. Elemente können im Content Browser organisiert werden, dies geschieht in sogenannte Packages (.upk Files). Diese Package Files lassen sich dann einfach verteilen und austauschen. Via Content Browser kann auch direkt auf andere Editoren, zum Beispiel der Material Editor zugegriffen werden. Ein weiterer wichtiger Aspekt des Browsers, ist die umfangreiche Suchfunktion mit ihrem Tagging System, jedes Asset kann mit Tags versehen werden, die Tags können dann im Browser gefiltert werden. Abbildung 20 Content Browser Übersicht 1. Assets (Texturen, Modelle, Materialien) 2. Quellen und Ordnerstruktur 3. Filter Christian Di Battista, Patrick Gloor Seite

40 4.5 Material Editor In älteren 3D Engines wurden Materialien durch eine einfache 2D Textur dargestellt. Mit dem Auftauchen von modernen Engines und deren Shaderfähigkeiten hielten sogenannte Materialien Einzug. Materialien sind 2D Texturen mit gewissen Shadereigenschaften, damit die Oberfläche realistischer wirkt. So können zum Beispiel Reflexionen, Transparenz, metallische Eigenschaften, Tiefenwirkung (Bump Maps) und vieles mehr auf die Texturen angewendet werden. Innerhalb von UDK werden die Materialien mit Hilfe des Material Editors erstellt und bearbeitet. Der Editor bietet eine sehr benutzerfreundliche Oberfläche an um die Materialien zu verwalten. Die Attribute und Funktionen können via Drag & Drop in die Arbeitsfläche gezogen werden und beliebig miteinander verbunden werden. Epicgames bietet auch zu den Materialien eine umfangreiche Dokumentation an. (udn.epicgames.com, 2012) Abbildung 21 Material Editor Übersicht 1. Alle Materialfunktionen 2. Hauptarbeitsfläche zum Bearbeiten der Materialien 3. Materialvorschau 4. Funktionsatrribute Christian Di Battista, Patrick Gloor Seite

41 4.6 Kismet Die Unreal Engine 3 bietet zum Realisieren von Interaktionen und Events eine eigens entwickelte Skriptsprache an: UnrealScript. In modernen Game Engines reicht jedoch ein einfaches Skriptsystem nicht aus, alles muss schnell von der Hand gehen und noch schneller getestet werden. UDK bietet dafür das Kismet Visual Scritping System an. Mit Kismet lassen sich Interaktionen und Events einfach zusammenklicken (im Hintergrund wird das Ganze mit UnrealScript aufgebaut). Mit Kismet lässt sich von einfachen Prototypen bis hin zu kompletten Spielen alles realisieren. (udn.epicgames.com, 2012) Abbildung 22 Kismet Editor Übersicht 1. Arbeitsfläche 2. Properties 3. Sequenz Editor Christian Di Battista, Patrick Gloor Seite

42 4.7 Matinee Matinee ist ein Sequenz Editor und wird immer in Kombination mit Kismet verwendet. Kismet löst ein Matinee Event aus, zum Beispiel das Betätigen eines Knopfes und dann wird die Matinee Sequenz initialisiert. Matinee wird für so gut wie alle Animationen in UDK verwendet, zum Beispiel das Öffnen einer Tür oder das autonome Bewegen eines Objektes von A nach B. Abbildung 23 Matinee Übersicht 1. Kurven Editor (Visualisierung der Sequenz) 2. Zeitachse 3. Properties Editor Christian Di Battista, Patrick Gloor Seite

43 5 Umsetzung Virtueller Rundgang In diesem Abschnitt wird beschrieben, wie die einzelnen Arbeitsschritte zur Realisation des virtuellen Rundganges umgesetzt wurden. Zu jedem Abschnitt werden auch die Schwierigkeiten erläutert, welche im Laufe der Arbeit aufgetreten sind. 5.1 Übersicht Um ein so komplexes Projekt wie den virtuellen Rundgang zu realisieren, ist man auf mehr als nur UDK angewiesen. Die Arbeitsschritte unterscheiden sich lediglich in ihrem Umfang von denen zur Erstellung eines vollwertigen Spiels. Man benötigt verschiedene Zusatzsoftware um zum gewünschten Resultat zu gelangen. Unterteilt wird das ganze Grob in die Bereiche: 3D Inhalte, 2D Inhalte sowie Interaktionen. Zu all dem benötigt man noch zusätzliche externe Ressourcen, wie etwa Fotos oder Logos. Die involvierten Systeme und deren Beitrag zum Projekt werden in untenstehender Grafik dargestellt. Autodesk Autocad Ressourcen Fotos für Texturen Externe Textur Websites HSLU CD Your+ Modell und Ressourcen 3D Inhalte Autodesk Maya 3D Modelle bearbeiten Modelle erstellen Modelle für UDK vorbereiten Speedtree Schnelle Erstellung von 3D Baummodellen für die Umgebung 2D Inhalte Adobe Photoshop Texturen bearbeiten Specular Maps CrazyBump Normal Maps TerreSculptor Height Maps Weight Maps Interaktionen / Userinterface Adobe Flash Erstellen von Inhalten wie Menus oder Dialogen Action Script Scaleform Clik Elemente UI Framework UDK Import von 2D und 3D Inhalten Import von Scaleform / Flash Inhalten Organisieren der Assets UDK ContentBrowser UDK Assets Assets werden verwaltet und in Paketen (.upk Files) gespeichert UDK Scripting Unreal Scripts oder C++ Scripts für die Erstellung von Inhalten wie Events, Aktionen oder sonstigen Interaktionen Konfigurations Files zum konfigurieren verschiedenere UDK Variablen Abbildung 24 Überblick UDK und Umgebung Christian Di Battista, Patrick Gloor Seite

44 5.2 Vorgehen Beim Vorgehen bei der Umsetzung, hat sich das Team stark an den Best Practices von Epic Games orientiert, da die Teammitglieder keinerlei Erfahrung mit dem Erstellen von virtuellen Welten hatten, war das Schema von Epic Games sehr hilfreich. In den nachfolgenden Abschnitten werden die einzelnen Schritte erläutert, es die Vorgehensweise erklärt und auf die aufgetretenen Probleme eingegangen. Christian Di Battista, Patrick Gloor Seite

45 Konzept Storyboard und Flashprototypen Mesherstellung Modell Import aus Autocad, Reduzieren des Modells Materialerstellung Texturen und Materialien Level Prototyp Model Prototyp Import Landschaft generieren Scripting Interaktionen Kamerafahrt Level ausarbeiten Modell Ausarbeiten Performance Optimiereung Beleuchtung und Meshes reduzieren Abbildung 25 Vorgehen Umsetzung virtueller Rundgang Christian Di Battista, Patrick Gloor Seite

46 5.3 3D Modell Einer der ersten Schritte des Projektes, war der Import des 3D-Modells, damit der Import in UDK überhaupt möglich war, waren einige Arbeitsschritte notwendig. Modell Erstellen AutoCAD Export DWG Import Maya UDK Überflüssige Teile entfernen, Objekt triangulieren Polygone Reduzieren Materialien anwenden FBX Modell unterteilen in kleinere Teilmodelle UV Mapping Kollisionsmodell Modell Plazieren Modell Bearbeiten Modell einsetzen Abbildung 26 3D Modell Workflow Christian Di Battista, Patrick Gloor Seite

47 5.3.1 Import in Maya Das Modell wurde von Your+ Architekten Team im CAD Programm Autodesk Autocad erstellt und als DWG (Drawing) Datei exportiert. Da das 3D Modellierungsprogramm Maya ebenfalls vom Hersteller Autodesk ist, lag es auf der Hand Maya zu benutzen um etwaige Kompatibilität Probleme zu vermeiden. Der Import lief problemlos ab, das Modell war bereits trianguliert und musste deshalb nicht noch nachträglich in Maya trianguliert werden Modell reduzieren Das importierte Modell wies eine Polygonen Anzahl von weit über auf. Das Importlimit in UDK liegt bei (für Vertices, Edges und Polygonen) dies ist eine Limitation des 16bit Indexbuffers für Static Meshes. Damit das Modell importiert werden konnte musste es erst reduziert werden. Dabei wurden sowohl die Geometrie vereinfacht, als auch überschüssige, für den Rundgang irrelevante Teile entfernt. Das genaue Vorgehen wird im HowTo Dokument im Anhang beschrieben Abbildung 27 Unbearbeiteter Prototyp Nach der Reduzierung des Objektes mussten weitere Schritte umgesetzt werden. Im Autocad File waren bereits Modellgruppen definiert, diese mussten aber für den Import in UDK neu erstellt werden. Gruppiert wurde dabei so, dass Objekte, welche dieselben Materialien haben, in die gleiche Gruppe abgelegt werden. Nachfolgend sind zwei Screenshots des Modells, einmal vor der Reduzierung der Polygonen und einmal nach der Reduzierung. Der Unterschied fällt sofort auf, das Reduzieren hat zudem den Vorteil, dass nach dem Import in UDK wesentlich weniger Rechenleistung benötigt wird um das Objekt auf dem Bildschirm darzustellen. Abbildung 28 Modell vor der Reduzierung der Polygonen Christian Di Battista, Patrick Gloor Seite

48 Abbildung 29 Modell nach der Reduzierung der Polygonen Kollisionsmodell Ein Kollisionsmodell ist für UDK wichtig, da ohne dieses Modell, das Objekt keine feste Form hätte, das bedeutet man könnte durch die Wände hindurchlaufen und auch andere Objekte (oder Effekte) würden nicht in der Lage sein mit dem importierten Modell zu kollidieren. Damit UDK weiss wo diese Kollisionen stattfinden muss ein Kollisionsmodell erstellt werden, dieses sollte wann immer möglich einfach gehalten werden, da das System ansonsten mehr Rechenleistung benötigt. Damit das Kollisionsmodel von UDK erkannt wird muss ein zweiter Layer mit demselben Namen und dem Prefix UCX erstellt werden. (udn.epicgames.com, 2012) Abbildung 30 Kollision Layers in Maya Christian Di Battista, Patrick Gloor Seite

49 5.3.4 UV Maps UV Maps sind wie schon im Einführungskapitel erwähnt, sind ein wichtiger Bestandteil im Modelling Workflow. Ohne die UV Maps können keine Texturen oder Materialien auf das Objekt angewendet werden. Das Erstellen sowie das Auslegen (Layout) der UV Maps ist eine langwierige Arbeit, insbesondere für ein so komplexes Modell. Bei den UV Maps gilt darauf zu achten, dass so wenig Überlagerungen wie möglich vorhanden sind. Normalerweise müssen die UV Maps im oberen Quadraten der sogenannten UV Shell liegen. Bei der Umsetzung gab es aber Probleme mit der Auslegung und so mussten die UVs ausserhalb der UV Shell platziert werden, UDK kann mit dieser Auslegung umgehen und so konnten die Texturen sauber auf das Modell übertragen werden. In untenstehender Abbildung ist die UV Map des Solar Decathlon Modells zu sehen. Abbildung 31 UV Maps des Modells Christian Di Battista, Patrick Gloor Seite

50 5.3.5 Export Um das Modell in UDK importieren zu können, muss es im sogenannten FBX (FilmBox, proprietäres Format, gehört heute Autodesk) Format sein. In Autodesk Maya ist die FBX Export Funktion standardmässig verfügbar. Damit das Modell in UDK sauber weiter verarbeitet werden konnte, musste der Export in drei Teilen erfolgen. Nach dem Export können die einzelnen Teile in UDK (mit standard Einstellungen) importiert und zusammengefügt werden. Abbildung 32 FBX Export Einstellungen Christian Di Battista, Patrick Gloor Seite

51 5.3.6 Probleme und Fazit Während der Realisierungsphase sind einige Probleme aufgetreten, insbesondere das fehlende Hintergrundwissen hat oft viel Zeit gekostet und verlangte nach umfangreichen Recherchen. Untenstehend werden die wichtigsten Probleme aufgelistet und beschrieben. Problem Zu komplexes Modell aus AutoCAD Fehlendes Wissen zum Thema 3D Modelling UV Mapping extrem aufwendig UDK Limitationen schlecht dokumentiert Hardware Limitationen Beschreibung Das ausgelieferte AutoCAD Modell des Your+ Teams, war viel zu aufwendig modelliert und es hat extrem Zeit gekostet dieses zu reduzieren. Unabhängig von der Eingesetzten Technologie (3D Modelling wäre so oder so nötig gewesen) war viel zu wenig Hintergrundwissen zum Thema vorhanden, das Team hat sehr viel Zeit zum recherchieren benötigt Der UV Mapping Prozess ist sehr zeitraubend und für komplexe Objekte, ohne Hintergrundwissen, fast nicht zu realisieren, deshalb wurde auch hier wieder viel Zeit zum Erarbeiten der Hintergrundinformationen gebraucht Obwohl das meiste in UDK sehr gut dokumentiert ist, fehlten wichtige Informationen zu eventuellen Limitationen beim Import von 3D Modellen Die Arbeit mit 3D Modellen ist rechenaufwendig und benötigt starke Hardware. Die Laptops des Projektteams waren nicht alle den Anforderungen gewachsen und so musste viel Arbeit auf anderen Rechnern erledigt werden. Tabelle 10 Probleme 3D Modelling 3D Modellierung ist ein extrem interessantes Thema, welches aber auch sehr viel Hintergrundwissen verlangt. Leider hatte das Team zu wenig Vorwissen aus dem Studium mitbringen können, um den Modelling Prozess optimal zu bearbeiten. Für eine künftige Arbeit in diesem Bereich, sollte das Modell bereits vorbereitet sein, oder die Arbeit müsste in zwei Projekte unterteilt werden, damit sich das Team genügend vorbereiten kann, gerade bei einer Arbeit wie dieser, wo ein funktionierendes Resultat erwartet wird. Durch hohe Zeitinvestitionen und gute Dokumentationen, konnte dennoch ein sehr gutes Resultat erreicht werden. Christian Di Battista, Patrick Gloor Seite

52 5.4 Interaktionen Ziel Ziel der Interaktionen, innerhalb des virtuellen Rundganges, ist die Berechnung des eigenen Energieverbrauches, um ihn am Ende des Rundganges mit dem des Solar Decathlon vergleichen zu können. Für die Ermittlung des Energieverbrauches werden gewisse Angaben benötigt die mit Fragen vom Messestand-Besucher abgeholt werden. Zusätzlich zur Berechnung wird auch das Solar Decathlon Pavilion präsentiert und beschrieben. Der Benutzer erhält somit ein Gesamtbild des Your+ Projekt Vorgehen Storyboard Um die Reihenfolge der Interaktionen, deren Inhalt und die Kamerafahrt zu visualisieren, wurde ein Storyboard erarbeitet (siehe Anhang). Für die Erstellung der Bildfolgen wurden Screenshots aus dem BIMx Desktop Viewer (Graphisoft, 2014) vom vorhandenen 3D-Modell verwendet und mit Grafiken für die Interaktionen / Kamerafahrt ergänzt. Das Storyboard wurde nachfolgend an den beteiligten Personen versendet und ein Feedback eingeholt Erstellung Interaktionen UDK bietet die Möglichkeit eigene In-Game Menus mittels Adobe Flash und ActionScript zu erstellen. Diese werden dank Scaleform GFx in UDK integriert und in Laufzeit dargestellt. Es wurde zuerst ein Mock-Up der Interaktionen (Flash Animation) erstellt und Feedbacks eingeholt. Die Flash Animation wurde dann in UDK importiert um eventuelle Probleme beim Import frühzeitig zu erfassen. Die Feedbacks wurden berücksichtigt um ein möglichst User-Friendly UI (User Interface) zu erstellen. Zu diesem Zeitpunkt enthielten die Interaktionen noch keine Logik für die Berechnung des Energieverbrauches. Sobald klar war welche Input Möglichkeit (Touch) dem Benutzer zu Verfügung stehen werden, wurden die Interaktionen in UDK mit einem Touchscreen getestet. Hier mussten einige Anpassungen an der Konfiguration von UDK gemacht werden um das Touchverhalten zu optimieren. Dies war aber keine grosse Hürde da UDK von Hause aus mobile Geräte unterstützt. Christian Di Battista, Patrick Gloor Seite

53 Grafiken (Logos, Background, usw ) Flash Umgebung UDK Laufzeit AS3 Scaleform Launcher Export SWF Import Scaleform GFx In-Game Menu HUD Interaktion Integration Wiedergabe Abbildung 33 Workflow Interaktionen vom der Flash Animation bis zur UDK Integration Christian Di Battista, Patrick Gloor Seite

54 Abbildung 34 Screenshot Interaktion Berechnung Energieverbrauch Für die Berechnung des Energieverbrauches (Strom und Heizung) wurden folgenden Fragen und Formeln verwendet. Als Datenquellen dient der typische Haushalt Schweiz 2013 (Bundesamt für Energie, 2014). Für die Ermittlung des Heizenergieverbrauches, je nach Gebäudeart, werden zusätzlich die Daten von WWF Schweiz verwendet (der typische Heizölverbrauch pro Quadratmeter). Falls eine andere Heizquelle als eine Ölheizung verwendet wird, dient der Wert als eine Näherung (es gibt Unterschiede bei der Effizienz). Die Fragen und Antworten stammen aus dem Footprint-Rechner von WWF Schweiz (WWF Schweiz, 2014) Gestellte Fragen Nachfolgend die Auflistung der Fragen und die möglichen Antworten in Klammern. In welchem Haustyp wohnen Sie? (Einfamilienhaus, Mehrfamilienhaus) Sind Sie Eigentümer oder Mieter? (Eigentümer, Mieter) Wie viele Personen leben in ihrem Haushalt? (1 bis 6) Wie gross ist Ihre Wohnung / Ihr Haus (nur beheizte Wohnfläche in Quadratmeter)? (<30, 30-50, 51-75, , , , , , >300) Welchem Standard entspricht Ihr Wohnhaus? (Baujahr vor 1980, Baujahr , Baujahr , Neubau nach 2009, Minergie (A) (Niedrigenergiehaus), Minergie-P (Niedrigstenergiehaus), Normale Sanierung, Sanierung nach Minergie Standard) Auf wie viel Grad heizen Sie Ihr Zuhause? (Auf über 23 C, Auf etwa 21 C, Auf maximal 19 C, Auf maximal 17 C) Welche Kühlgeräte haben Sie? (Kühlschrank und Tiefkühltruhe, Kühlschrank mit kleinem Gefrierfach) Enthält Ihr Haushalt ein Geschirrspüler? (Ja, Nein) Wie bereiten Sie ihr Warmwasser auf? (Mit der Heizung, Mit einem Elektroboiler) Wie hoch ist der Anteil an LED, Leuchtstoffröhren oder Energiesparlampen in Ihrem Haushalt? (Weniger als 20%, 40 bis 50%, Mehr als 80%) Christian Di Battista, Patrick Gloor Seite

55 Berechnung Nachdem alle Antworten erfasst sind wird die Berechnung in zwei Schritten ausgeführt. Zuerst wird der Stromverbrauch ermittelt, wobei als Basis-Wert der typische Schweizer Durchschnitt von 2013 genommen wird. Siehe Tabelle: Haustyp Personenzahl Basiswert kwh/jahr Anteil Sparlampen < 20 % Anteil Sparlampen > 80% Kein Geschirrspüler Zusätzliches Gefriergerät Warmwasser mit Elektroboiler Mehrfamilienhaus Einfamilienhaus Tabelle 11: Basiswerte des typischen Haushalt 2013 (energieeffizienz.ch, 2013) Dieser Basiswert, je nach Anzahl Personen und Haustyp, ist folgendermassen definiert: Ohne elektrisch erwärmtes Warmwasser Ohne separates Gefriergerät Mit Geschirrspüler Anteil Sparlampen 40 bis 50 % Falls die Angaben des Messestand-Besuchers nicht mit dem Basiswert übereinstimmen, werden die nötigen Anpassungen gemacht. (siehe Tabelle oben) Nach der Berechnung des Stromverbrauches folgt die der Heizenergie. Diese wird folgendermassen berechnet: Heizenergie (kwh/jahr) = (Liter Heizöl x Fläche x 10 kwh) / Fläche Quelle: (umwelt-luzern.ch, 2014) Christian Di Battista, Patrick Gloor Seite

56 Wobei die Anzahl Liter Heizöl je nach Gebäudestandard variiert: Gebäudebau -Standard Liter Heizöl pro m2 im Jahr Baujahr vor Baujahr Baujahr Neubau nach Minergie (A)(Niedrigenergiehaus) 4 Minergie-P (Niedrigstenergiehaus) 3 Normale Sanierung 10 Sanierung nach Minergie Standard 6 Tabelle 12 Typischer Schweizer Heizölverbrauch (WWF Schweiz, 2014) Diese Werte enthalten auch die Warmwasser-Zubereitung und eine Heiztemperatur von 21 C. (immoga.ch, 2013) Falls der Besucher eine andere Wohntemperatur angibt, wird der Energieverbrauch, je nach Temperatur, angepasst: Für 23 C +12% Für 19 C -12% Für 17 C -24% ( +/- 1 C entspricht ein +/- 6% an Heizenergie (2000watt.ch, 2013) Man beachte dass die Angaben Mieter oder Eigentümer nicht die Berechnung beeinflusst. Sie wird jedoch benötigt um am Ende sinnvolle Verbesserungsvorschläge geben zu können Auswertung Nach den Berechnungen von Strom- und Heizenergieverbrauch werden die Energieklassen zugeteilt. Für die Unterteilung der Energiewerte in Energieklassen, haben wir Anhand von Referenzwerten folgende Aufstellung definiert: A B C D E F G <= 50% <= 70% <= 90% <= 110% <= 130% <= 150% > 150% Tabelle 13: Zuordnung zu Energieeffizienz-Klassen (Prozent des Energieverbrauchs im Vergleich mit dem Schweizer Durchschnitt Somit, falls der Energieverbrauch zwischen 90 und 110% im Vergleich mit dem Schweizer Durchschnitt liegt, wird ein Energieverbrauch der Klasse D vergeben. (Schweizer Durschnitt liegt bei D) Diese Aufstellung entspricht keinem bekannten Standard, da ein solcher für Strom und Heizenergieverbrauch nicht definiert ist (laut unserer Recherchen). Wir haben aber als Referenz die von Haushaltsgeräten verwendet (wikipedia.org, 2014). Die Zuteilungen erfolgen in drei Schritten: 1. Zuteilung des Stromverbrauches: Christian Di Battista, Patrick Gloor Seite

57 Nach Berechnung des Stromverbrauches wird das Ergebnis mit dem typischen Basiswert verglichen. Je nach Prozent werden die Klassen A bis G zugeteilt. 2. Zuteilung des Heizenergieverbrauches Nach Berechnung des Heizenergieverbrauches wird daraus die Energie-Kennzahl berechnet. Diese wird dann mit dem Basiswert von 120 verglichen, welcher der Mittelwert zwischen dem Schweizer Durchschnitt EFH und MFH ist. (EFH 140 kwh/m2/jahr, MFH 100 kwh/m2/jahr). Der Mittelwert ist nötig, da der Haustyp (EFH oder MFH) nicht in den Berechnungen des Heizenergieverbrauches einfliesst. 3. Berechnung des Mittelwertes Nachdem die beiden Energieklassen bekannt sind (Strom und Heizung), wird ein arithmetisches Mittel berechnet und dies dann verwendet. Die ermittelte Energieklasse wird somit dem Besucher bekanntgegeben, in vergleich mit der Energieklasse des Solar Decathlon Pavillons. Da wir am noch keine Angaben des Energieverbrauches vom Solar Decatlon Team erhalten haben, haben wir eine Klasse A zugewiesen. Abbildung 35 Darstellung Ergebnis (Bsp. Resultat Klasse A) Implementation Die Berechnungen können in der Flash Animation implementiert werden, wurden aber auf UDK-Seite ausgelagert wegen Performance-Gründen, wie auch von Scaleform empfohlen. Für weitere Informationen wird auf die Systemspezifikation verwiesen. Christian Di Battista, Patrick Gloor Seite