WEATHERWORLD - 3D Weather Forecast Visualisation Application

(1)

W EATHER W ORLD

-

3D Weather Forecast Visualisation Application

Gregory John Paul Marsh Candidate Number: 119855

MSc Computing with Digital Media School of Engineering & Informatics

University of Sussex

2014

(2)

Statement of Originality

This dissertation is submitted as part requirement for the MSc in Computing with Digital Media at the University of Sussex. It is the product of my own labour except where indicated in the text. The report may be freely copied and distributed provided the source is acknowledged.

Signed:

Gregory John Paul Marsh 01/09/2014

(3)

iii

Abstract

The aim of this project was to develop a weather forecast application that communicated the

forecast via the medium of a 3D computer-generated environment and to establish the effectiveness of such an approach. This was to be done using computer game development techniques to create an immersive, engaging and novel forecast visualisation.

The application was created within Microsoft Visual Studio, written in C# and used the object- oriented graphics rendering engine MOGRE. A dynamic 3D interactive environment was developed with additional features such as integrated audio and a graphical user interface. A live forecast feed was implemented using an online weather forecast API. Additional development tools included Autodesk 3ds Max for creating the 3D models contained within the environment and Adobe Photoshop to create the model textures and elements of the user interface.

The end product proved that such an application could be successfully built and that the 3D environment could function as a weather forecast communication tool, as was the aim. The entire process, from research and design through to implementation and user testing, is described and discussed within this report.

(4)

iv

Acknowledgements

I would like to thank my supervisor, Dr Paul Newbury, for his guidance and encouragement during the project process.

I would also like to thank the University of Sussex for awarding me the Chancellor’s Masters

Scholarship for my place on the MSc in Computing with Digital Media, for which this dissertation was written.

Finally, I would like to thank my family and friends who have ceaselessly supported me throughout this project and the degree course as a whole.

(5)

v

List of Figures

Figure 2.1: Examples of online weather forecast displays ... 3

Figure 2.2: Examples of iPad weather apps ... 4

Figure 2.3: Examples of ‘false’ 3D environments in weather apps ... 4

Figure 2.4: TrueWeather 3D application screenshot ... 5

Figure 4.1: Storyboard for user path through the application and initial GUI layout sketch ... 12

Figure 4.2: Storyboard sketch for environment dynamics ... 13

Figure 4.3: System overview diagram ... 14

Figure 4.4: Simplified UML Diagram ... 15

Figure 4.5: 3D environment layout design ... 16

Figure 4.6: Initial 3D model of environment ... 17

Figure 4.7: Prototype mock-up of GUI layout ... 18

Figure 5.1: Initial basic MOGRE generated 3D environment ... 19

Figure 5.2: XmlNodeList code excerpt ... 20

Figure 5.3: getWindDirection code excerpt ... 21

Figure 5.4: 3ds Max polygon editing for house frame creation... 21

Figure 5.5: Original brick wall image sourced online and edited version with texture map for the house frame polygon mesh in 3ds Max ... 22

Figure 5.6: Fully textured model of the house and surrounding items ... 23

Figure 5.7: Multiple versions of the time bar GUI element ... 25

Figure 5.8: Time bar interactions ... 25

Figure 5.9: Timer code excerpt ... 26

Figure 5.10: Full GUI implementation ... 27

Figure 5.11: Skyboxes for a clear sunny day at 9am and a moonlit night sky at 9pm ... 28

Figure 5.12: Different skybox and lighting conditions at sunrise and night time ... 29

Figure 5.13: Snow/rain weather grids that were produced during the experimentation stage ... 30

Figure 5.14: Rainfall conditions and snow conditions at different times of day ... 31

Figure 5.15: Morning fog conditions ... 32

Figure 5.16: ‘if’ statement for GUI text colour change ... 33

List of Tables

Table 2.1: Weather Underground API list of weather conditions ... 8 Table 4.1: Time management plan ... 11-12

(8)

1

1. Introduction

1.1 Background

With the proliferation of progressively more advanced technology becoming available to an ever increasing proportion of the population, the opportunity for developers to provide sophisticated and engaging multimedia tools has grown. This is particularly evident within the mobile device

application market, encouraged by an extremely competitive hardware and software development race between rival manufacturers. Applications installed on mobile devices are providing both information and entertainment to users. The demand for such applications is evidenced by the 250 million apps downloaded in Q2 2014 from the iOS and Android app stores (Kedia, 2014).

One such example is that of weather forecast information. Weather forecasts are used by all

sections of society and with varying levels of importance ranging from essential weather information used for maritime navigation or weather condition monitoring for major outdoor events down to everyday planning of an individual’s journey to work or social plans. As such, this is an area that has a significant presence online and within the app market. Dedicated weather forecast websites with associated applications for a multitude of platforms exist, AccuWeather being a prime example (AccuWeather Inc., 2014b). Weather also competes for space on news websites, such as the BBC’s homepage (BBC, 2014a), up against News, Sport and Entertainment.

There are many different ways of presenting this information and significant variations in the level of detail provided dependent upon the target user. Common forms of forecast formats include detailed graphs and data tables, simplified icon graphics, computer-generated graphical representations and live satellite images.

1.2 Proposal

The proposal for this project was to produce a weather forecast application (named

‘WeatherWorld’) that displayed the forecast via the medium of a 3D environment. The aim was that the environment replicated real world conditions and so the forecast could be interpreted by the user in a similar way to how they experience the current weather conditions around them. This was an attempt to provide a relatively novel way for the user to view the forecast with the intention that it was informative but also entertaining and enjoyable to use.

The environment was proposed to be created using similar software packages and techniques as used for 3D computer game production. This was to allow for engaging and immersive graphic visuals as well as dynamic changes to the environment. Changes to the environment were to be driven by forecast data provided by an online application programming interface (API). Alongside the visual environment, integrated audio effects were planned to enhance the user experience and aide in the communication of the forecast to the user.

A key challenge for the project was to produce computer graphics of a high standard that could be manipulated in real-time and with enough versatility to represent all potential weather conditions as well as other factors such as time of day. This had to be achieved with an appreciation for the demands on the graphics processing unit (GPU) of the computer to ensure that the application could run with a sufficient level of performance (i.e. smooth animation, quick response to user inputs).

(9)

2 The project aimed to produce a fully functioning version of the application that could run within the chosen development environment on a desktop PC. It was viewed that, if developed further beyond this project, the application would most likely be built for mobile devices and so in that respect the application produced here was a proof of concept for further multi-device development.

1.3 Approach

The first stage of the project was to carry out background research in order to approach the application build in an appropriate manner. This involved observing existing solutions in this area, investigating the software packages available for the implementation and considering the

characteristics of weather conditions including the current computer graphics techniques used to simulate them.

A set of requirements was then established before a suitable design was drawn up in response to them. The implementation followed the design with the key elements being the 3D environment build, the integrated audio, the graphical user interface of the application and the weather forecast data feed management.

Once an initial functioning version of the application was built, user testing was carried out in order to gain independent reflection on the application’s quality from a user’s perspective. These user tests along with self-testing of code and performance were part of an iterative design approach with the results evaluated and fed back into the implementation process. The intention of this approach was to produce an application that met all of the stated requirements.

1.4 Report Overview

This report provides a comprehensive description of the project process and is structured as follows.

Chapter 2 summarises the background research carried out and the relevant findings. Chapter 3 sets out the requirements of the project as informed by the project proposal and the background

research. Chapter 4 outlines the project plan and the design of the application in terms of overall system structure, code structure, 3D environment and Graphical User Interface. Chapter 5 focuses on the implementation of that design with details of the methods used and challenges faced. In Chapter 6 the program code testing process is explained. Chapter 7 describes the evaluation of the application by means of a user test. Finally, chapter 8 concludes the report with a discussion of the project’s end product, limitations and potential future development.

(10)

3

2. Review of Related Research

2.1 Existing Solutions

Research showed that weather forecast information can be found in a multitude of formats online.

There were some common elements to virtually of all of these formats such as an icon or image to represent the weather condition, a numerical temperature display as well as clear reference to the time and location of the forecast.

Figure 2.1: Examples of online weather forecast displays. Clockwise from top left: list display on Met Office website(Met Office, 2014b), simple icon display BBC weather website (BBC, 2014b), satellite image display at Accuweather.com (AccuWeather Inc., 2014c), image display also at AccuWeather.com.

All of these different display formats had the aim of communicating the forecast to the user in the most efficient way possible. In many cases, visual aides were used alongside data in order to reduce the clutter of text and numbers and produce a clear, instantly comprehensible forecast. For

example, the format used on the BBC weather website (BBC, 2014b) contained much less text than that seen on the Met Office site (Met Office, 2014b) and yet could be considered more successful in communicating the forecast (see Fig. 2.1 top right and top left respectively). This was achieved by bold use of recognisable icons, positioning and colour. The AccuWeather site (AccuWeather Inc., 2014c) used a more true to life image to represent the weather conditions, which attempts to provide more information than a simple icon (Fig. 2.1 bottom left). Another technique used on the same site was to place weather condition icons over satellite images of the relevant forecast area (Fig. 2.1 bottom right).

(11)

4 Applications that are dedicated to weather forecast information were seen on both desktop and mobile platforms. These offered a tailored forecast display for the user’s device and so could provide a more sophisticated layout that best utilised the hardware and software available.

Figure 2.2: Examples of iPad weather apps. Clockwise from top left: The Weather Channel App for iPad (The Weather Channel Interactive, 2014), Weather Live Reloaded (Apalon Apps, 2014), World Weather Radar (International Travel Weather Calculator, 2014b), Alarm Clock & Weather HD (Postindustria, 2014), Living Earth – Clock & Weather (Radiantlabs LLC, 2014), Celsius Free (International Travel Weather Calculator, 2014a).

In Figure 2.2 a small selection of the many weather forecast applications found on the Apple iOS market can be seen. Applications such as these were custom made for a touch screen interface with a high resolution 4:3 screen. Use of large high quality images, animated elements and interface metaphors enhance the user experience and differentiate the available apps from one another.

Within the current market there were very few weather apps available utilising 3D graphics, as was the aim with this project. Some applications had taken a similar approach to the one proposed here by creating a dynamically changing environment but in most cases this was achieved using a false 3D effect (see Fig. 2.3). This was done with animated layers for different elements of the environment combined to produce a high definition composite image. However, as these were not rendered in 3 dimensions the environments could not be freely navigated or viewed from multiple angles.

Figure 2.3: Examples of ‘false’ 3D environments in weather apps. Left to right: 3D Weather Forecast (Mobilityflow &

Kbitubit, 2014), 3D Weather Live Wallpaper (maddy, 2014), True Weather Waterfalls (Vivoti Studio, 2014).

(12)

5 Only one application was found comparable to that proposed here, with a navigable 3D environment and animated ‘real-world’ conditions. The app, called TrueWeather 3D (Vivoti Studio, 2013), was available on the Google Play market for Android mobile devices (see Fig. 2.4). This app functioned as a mobile device background and only used the 3D environment to display the current weather conditions for a specified location with the actual forecast displayed in a more traditional text and icon format. And so, although the use of 3D was close in concept, it was not the same in that it did not allow as much user interaction and manipulation of the environment as proposed in this project.

Figure 2.4: TrueWeather 3D application screenshot (Vivoti Studio, 2013).

Having analysed the current solutions in the market it was clear that the application being developed offered some novel features. Although the TrueWeather 3D application was similar in terms of the technical implementation (3D environment, animations, navigation), it did not use the graphically advanced environment to communicate the forecast so much as it was there purely as an

aesthetically pleasing background theme based upon current weather conditions. This backed up the justification of the applications development as valid research.

Observations of all these weather forecast platforms assisted with the design process for this application even though the format and medium used differed in most cases. For example,

consideration of usability design principles such as consistency and mapping, as defined by Donald Norman in The Design of Everyday Things (1998), could be replicated and applied as they had been in existing solutions.

2.2 Software Selection

There were a variety of software development tools available for each of the key elements of this project; the development language and environment, the 3D modelling and the weather forecast API. All available options had to be considered, weighing up their relative strengths and weakness for fulfilling the needs of the project. Another factor that had to be considered was existing knowledge of and experience with the software packages due to the potential opportunity cost of learning time.

(13)

6 2.2.1 Development Language and Environment

When choosing a development language and environment the key factor was to find one that could fully support 3D environment rendering. This naturally lent itself to 3D computer game development software within which there are a great deal of options. Significant time was spent researching this area and assessing the alternatives. Online articles by Craig Chapple (2014) and Mark Masters (2014) as well as the 100 Highest Rated Engines blog (ModDB, 2014) were a good starting point for this.

This being the main element of the development toolkit for the project, the first option considered was MOGRE (Torus Knot Software Ltd., 2011) as this was the most familiar in terms of hands-on experience. Standing for Managed OGRE, MOGRE is a .NET wrapper for OGRE (OGRE standing for Object-Oriented Graphics Rendering Engine) and so allows for C# programming within the C++

environment of OGRE. OGRE differed from many of the options in that it is not a computer game engine but rather a 3D rendering engine. This meant that it did not include all the features required for computer game development such a physics engine, audio support and asset libraries. OGRE (and in turn MOGRE) did however have a comprehensive selection of add-on libraries available to support such features and so could be tailored to the needs of the project. As this project did not involve full computer game development, the versatility and customisable nature of the

development environment was beneficial. Other benefits included the active online community support available and the fact that it is open source with no licence fee. The main disadvantage to MOGRE is that it is not as powerful a 3D rendering engine as some of the main alternatives.

Two other options under consideration were Unreal Engine 4 (Epic Games Inc., 2014b) and Unreal Development Kit (Epic Games Inc., 2014a). Unreal Development Kit is the free version of Unreal Engine 4’s predecessor Unreal Engine 3. Both are dedicated computer game engines that offer a comprehensive list of game production features and use C++ based programming languages. The main difference is that Unreal Engine 4 is more advanced and with that benefit comes a licence fee cost whereas Unreal Development Kit is free until produced content is commercially released.

Another option was CryENGINE (Crytek GmbH, 2014), a very powerful computer game engine that was considered by various sources to be the most advanced on the market. As with Unreal Engine 4, CryENGINE required a licence fee and although it boasted strong performance it was known to be not very user-friendly, requiring significant learning time.

The final game engine given serious consideration was Unity 4 (Unity Technologies, 2014). This software offered strong online community support due to its versatility and relatively user-friendly interface. It was also available in both free and pro versions and so did not require a licence for initial development. One disadvantage against some of the alternatives was that it was not the most powerful of 3D engines.

With all these options considered, the deciding factor was previous experience with the software packages. Within the timeframe of the project it was considered too costly to devote a significant amount of time to learning a new development environment and so MOGRE was selected to be written in C# using the integrated development environment Visual Studio 2010 (Microsoft Corporation, 2010). Although the least powerful of the above options, it was capable of producing 3D graphics to the standard required and the familiarity with it and with the C# language allowed for the most efficient use of time. The add-on libraries also meant all potential features needed were supported such as audio, a physics engine and graphical user interface constructors.

(14)

7 2.2.2 3D Modelling Software

This software was to be used to create the 3D models present in the environment before importing them into the main development environment. As such, two key considerations were the modelling capabilities of the software and the compatibility with the chosen development tool (MOGRE).

There were once again many options available but the three main modelling software packages looked at were 3ds Max (Autodesk, 2013), Maya (Autodesk, 2014) and Blender (Blender Foundation, 2014). They all offered very powerful modelling features and were supported for import to MOGRE.

With very little to suggest that any one of them offered significant benefits within the demands of this project it was once again a decision based on previous experience, and so 3ds Max was chosen.

2.2.3 Weather Forecast API

The choice of weather forecast API was one that had to be made with consideration as to what would be required to drive the dynamic environment changes as well as some additional display information. At this stage of the project an open view was required as the exact requirements of the forecast data feed to the 3D environment were not known. With that in mind various options were evaluated and it was accepted that, even if an API was chosen early on, a switch to one of the alternatives may be needed at a later date.

With only limited experience of weather API use, online articles regarding weather API selection were read in order to gain a view of what was available. An online article by Kanishk Kunal (2014) and an online blog entry by Michael Welburn (2011) were of particular use. As a result, a selection of weather APIs were scrutinised and three of these are discussed below.

OpenWeatherMap API (Extreme Electronics Ltd., 2014) offered a good option in terms of data field coverage, free use and the most accurate location specification down to coordinate level. The focus of this API was to provide weather forecast maps and map-related functions, an advanced feature but not one required for this project. There was also only forecast data for 3 hour intervals for the 5 day forecast and only daily data for the 16 day forecast, which was seen as restrictive compared to other options.

Weather Underground API (Weather Underground Inc., 2014) was another with a strong data field coverage and flexible location specification with area codes and city names accepted. This API was also available free for developers within a limit of 500 calls to the API per day. This limit was sufficient for the project’s needs although perhaps in the long term the worth of a premium subscription would need to be assessed. One of the most attractive characteristics of this API was the hourly forecast data available for a 10 day forecast period. This would provide great flexibility going forward in terms of forecast time intervals within the application.

Another possibility was the AccuWeather API (AccuWeather Inc., 2014a). With AccuWeather being a major presence within the online weather forecast market it was natural to look at this as an option.

The data and accuracy provided by AccuWeather matched all other APIs and even went down to a minute-by-minute forecast for a limited period, although this was not required. This API did not offer a free use subscription and so any benefits of it over others had to be weighed up against that cost.

With many options reviewed, the Weather Underground API was selected as at least the initial development tool for the application. This choice was due to all required data fields being available

(15)

8 on an hourly basis for a 10 day forecast period with no subscription costs. If at a later stage this API had not provided the necessary input to the system, or if any performance issues arose, then the AccuWeather API could have been employed.

2.3 Weather Attributes and Computer Game Implementation

Investigation specifically into weather conditions and how they might be implemented within a 3D computer game environment was undertaken. This would be necessary prior to commencing the design process. Although it was accepted that some aspects of the design and implementation would require an iterative approach involving experimentation and trial and error, it would be advantageous to be aware of existing techniques.

Firstly, the range of potential weather conditions was assessed. Putting together a list of possible conditions was easily done by studying the documentation provided with the weather forecast API.

The application would be limited to the same list of conditions as contained in the selected API. By evaluating the list associated with the Weather Underground API, it was ascertained how many actual visually distinct conditions might exist within the developed environment. For example, within the API there were different forecast codes for “Snow” and “Snow Showers” although these would most likely be treated as the same condition in terms of 3D graphical representation. Table 2.1, below, shows the full list of forecast codes (left) and then the same list sorted into visually distinct groups (right). This was an initial grouping that could have been subject to change.

Table 2.1: Weather Underground API list of weather conditions. Those present within the Weather Underground API (left).The same list sorted into groups of conditions with visually common attributes (right).

(16)

9 With previous 3D computer game development experience to draw from, some of the weather conditions identified appeared to present more of a challenge than others. For example, it was known that the MOGRE 3D engine supported fog simulation within its core library of methods and so at least from an initial evaluation it was felt that techniques were in place to handle that. In contrast to that was how to approach the simulation of rain and snow conditions. These two weather types were identified as a particular challenge and so, during the research process, were given more attention.

This stage of the research process involved general reading around the subject of weather simulation in computer game environments. The internet provided a great resource for such information with many articles and blogs on the subject. One of the first articles read was an online paper by Matt Barton (2008) that covered the history of weather simulation within game

environments and the importance of weather in creating immersive environments. Although the article did not cover technical implementation it did highlight some of the challenges that weather conditions present to game developers such as the demands put on the GPU negatively effecting performance (slowing frame-rate).

Of particular use from a technical perspective was a 3-part article on fxguide.com by Mike Seymour (2013) discussing game environment creation with particular focus on rain and wet conditions. The article discussed, and had examples of, real world references as well as detailing methods used in commercial game development.

In addition, existing examples of in-game weather conditions from commercially released titles were observed to assess what might be possible and gain an understanding of what visual cues the developers had used. These games included Tomb Raider: Definitive Edition (Crystal Dynamics, 2014), Grand Theft Auto V (Rockstar North, 2013) and The Last of Us (Naughty Dog Inc., 2013). The visual aspects of weather present were analysed and reflected on, and informed the design process and experimental aspects of the implementation.

(17)

10

3. Requirements

The requirements of the project were defined as follows:

1. The system must be built using a 3D development environment that supports externally created 3D models.

2. The application must contain a textured and well-rendered 3D ‘outdoor’ environment containing, as a minimum, the following elements:

- Main building (including visible internal structure and lighting) - Surrounding terrain

- Surrounding sky

- Object(s) that can be subject to wind direction, e.g. a tree, a weather vane or a washing line

- Object(s) to identify the orientation (north, east, south, and west) of the environment (unless this is achieved through the GUI)

3. Within the environment there must be realistic and dynamic lighting that replicates sunlight and ambient light for all times of day/conditions.

4. Using 3D computer game development techniques the application must be capable of rendering animations and environmental changes to simulate, as a minimum, the following weather types:

- Sunshine - Cloud cover - Rain - Snow

- Thunder & Lightning - Fog

- Wind

5. Audio must be integrated into the system so that visual changes are enhanced by audio effects. This must include ambient sounds for different times of day as well as weather condition specific sound effects.

6. The application must receive a live weather forecast feed and use this information to drive the time of day and weather condition changes within the 3D environment.

7. The application must allow the user to view the weather forecast in hourly intervals for a period extending forward to 10 days from the current time.

8. The application must allow the user to view the weather forecast in more than one location.

9. The application must include a graphical user interface to display location, time and weather forecast information (obtained from the weather forecast feed). It must also allow for user interactions such as selecting forecast location and forecast time as well as different viewing options.

10. The application must operate, on the computer used to develop it, with an acceptable level of performance. Factors such as smooth animation, frame-rate and fast response to user input will be used to judge these and will be seen as acceptable if in line with similar existing applications.

(18)

11

4. Planning & Design

With background research completed and a full set of requirements established it was essential to fully prepare for the implementation stage of the project. The first step was to formalise a planned time schedule of expected tasks including task duration and inter-task dependencies. The initial design stage was to storyboard the application’s use and functionality to help in identifying specific features and functions within the system. This was followed by the production of a comprehensive design of the application’s programming code structure, 3D environment and graphical user interface.

4.1 Planning

An initial time plan for the key stages of the project had been drawn up at the beginning of the process but once research had been completed and requirements established, a more thorough plan was put in place. Time was allocated for each required element of the project with analysis done to determine the duration and order based on dependencies between tasks.

Below is the full list of tasks within the time management plan (see Appendix A for Gantt chart of the time management plan including dependencies).

Name Start Finish Duration

Kick-off Meeting Thu 15/05/14 Thu 15/05/14 1 day

BACKGROUND RESEARCH Fri 23/05/14 Mon 02/06/14 11 days

Software Selection Fri 23/05/14 Mon 02/06/14 11 days

Existing Solutions Fri 23/05/14 Mon 02/06/14 11 days

Weather Fri 23/05/14 Mon 02/06/14 11 days

Set Of Requirements Tue 03/06/14 Thu 05/06/14 3 days

DESIGN Fri 06/06/14 Wed 11/06/14 6 days

Story Boarding Fri 06/06/14 Sun 08/06/14 3 days

System Structure & Code Design Mon 09/06/14 Wed 11/06/14 3 days User Testing Ethical Review Submission Thu 12/06/14 Fri 13/06/14 2 days Dissertation BG & Design Write Up Sat 14/06/14 Mon 16/06/14 3 days

IMPLEMENTATION Tue 17/06/14 Sun 27/07/14 40 days

Code Structure Setup Tue 17/06/14 Fri 20/06/14 4 days

3D Modelling Sat 21/06/14 Wed 23/07/14 32 days

Initial 3D Model Sat 21/06/14 Wed 25/06/14 5 days

Refine 3D Model Sun 20/07/14 Wed 23/07/14 4 days

User Interface Thu 26/06/14 Sat 28/06/14 3 days

Weather Simulation Sun 29/06/14 Fri 11/07/14 13 days

Wind Sun 29/06/14 Tue 01/07/14 3 days

Snow Wed 02/07/14 Fri 04/07/14 3 days

Rain Sat 05/07/14 Mon 07/07/14 3 days

Fog Tue 08/07/14 Wed 09/07/14 2 days

Lightning Thu 10/07/14 Fri 11/07/14 2 days

Sound Effects Sun 13/07/14 Mon 14/07/14 2 days

(19)

12

Background Sun 13/07/14 Sun 13/07/14 1 day

Weather Specific Mon 14/07/14 Mon 14/07/14 1 day

Dissertation Implementation Draft Write Up Tue 15/07/14 Fri 18/07/14 4 days

Initial Self Evaluation Sat 19/07/14 Sat 19/07/14 1 day

Code Review Thu 24/07/14 Sun 27/07/14 4 days

TESTING & EVALUATION Mon 28/07/14 Mon 11/08/14 8 days

User Testing Tue 05/08/14 Wed 06/08/14 2 days

Evaluation and Refinement of Program Thu 07/08/14 Mon 11/08/14 5 days

REVISE DISSERTATION Tue 12/08/14 Fri 29/08/14 18 days

Write Introduction, Further Work, Conclusion Tue 12/08/14 Wed 13/08/14 2 days Revisit BG, Design & Implementation Thu 14/08/14 Fri 15/08/14 2 days

Review Feedback Sat 16/08/14 Sat 16/08/14 1 day

Final Draft Write Up Sun 17/08/14 Sun 24/08/14 8 days

Review further feedback & final administrative tasks Mon 25/08/14 Fri 29/08/14 5 days

SUBMISSION DEADLINE Mon 01/09/14 Mon 01/09/14 1 day

Table 4.1: Time management plan.

4.2 Storyboarding

In order to translate the set of requirements into a tangible design, the process of storyboarding was used. This is a technique heavily relied upon within the digital media industry (and others) to

generate ideas around the way a product will look and feel as well as exploring user behaviours and potential features.

As an informal process, this largely involved annotated sketches, brainstorming and flow diagrams.

The possible actions of a user were examined to gain an understanding of what they might expect from a weather forecast application such as this. The aim of this was to anticipate user actions and expectations, identifying the options and interface functions they would need to be provided with in order to facilitate and meet them. The examples below (Fig. 4.1) show an early user path flow diagram (left) and an initial sketch of the graphical user interface (GUI) layout.

Figure 4.1: Storyboard for user path through the application (left) and initial GUI layout sketch (right).

(20)

13 Figure 4.2 (below) shows an annotated drawing of the possible elements to be contained in the application’s 3D environment. It was at this stage that the mechanics of communicating the forecast via a 3D graphical environment were considered in greater depth.

Figure 4.2: Storyboard sketch for environment dynamics.

4.3 System Overview

The system that made up the application build comprised of a variety of elements including software packages, programming code, 3D models, audio files and images.

Central to the system was the program, written in C# within the Microsoft Visual Studio suite. The graphics rendering engine MOGRE was installed so that its library of resources could be used within Visual Studio as well as add-on libraries for unsupported functions such as audio. Three key areas within the program were the 3D environment, the GUI and the audio.

Within the program a call to the Weather Underground API was to be made so that forecast data could be received and used by the application. Once the forecast data had been received, the program would use that to define the parameters of the 3D environment and the audio as well as the GUI. The GUI would then allow the user to interact with the program and control the location and period of the forecast displayed as well as the viewing angle.

3ds Max was used to produce the 3D models contained in the 3D environment. The models were then exported from 3ds Max into a format compatible with the MOGRE engine. Photoshop (Adobe Systems Incorporated, 2014) was an essential tool for creating textures for the 3D models built in

(21)

14 3ds Max as well as some elements of the 3D environment produced directly in Visual Studio using MOGRE. Photoshop was also used to create the visual components of the GUI.

The system and the interactions between its different elements are illustrated below (Fig. 4.3).

Figure 4.3: System overview diagram.

4.4 Programming Code Structure

The programming code structure developed throughout the implementation process although the basic concept remained the same. The design described here is the final version; see Figure 4.4 below for the simplified UML diagram (fields and methods are not included).

The starting point for this design was a previously completed project built in Visual Studio with MOGRE. That project used MOGRE to power a 3D computer game. Although that game functionally differed greatly to the application developed here, the setup of the environment and some of the methods used were also planned to be employed and so considerable time was saved by taking this approach. The previous project itself was developed from tutorial components of code provided as part of an Interactive 3D Programming module held at the University of Sussex (Gilardi, 2014). The classes that have remained unchanged from those provided are ModelElement, MovableElement, GameElement, HMD and MouseCursor.

Below is a description of the key classes and their primary functions within the structure:

WeatherWorld – This class was the centre of the programming code structure. It contained the main method to launch the program and all the key methods needed to construct a visual 3D environment using MOGRE. This included classes for creating and destroying the scene, creating the cameras and viewports as well as updating the program each frame. Within this class instances of the

Environment, WeatherForecast, ProgramData and WWInterface classes were created. This class was also used to control the program data for location and forecast code changes.

WeatherForecast – This class’s primary use was to make the call to the Weather Underground API and organise the different fields of forecast data as lists. Various ‘get’ methods were written to allow the forecast data to be accessed and used in other classes.

(22)

15 ProgramData – This class acted as a hub for the data fields used throughout the program with ‘get’

and ‘set’ methods in place for each. This allowed for clear and consistent handling of these fields that required access from multiple classes but with only one instance present throughout the program.

InputsManager – The mouse movements and button presses as well as the keyboard key presses were monitored and identified within this class. An important function of this class was to recognise when the mouse cursor was over the GUI’s buttons.

WWInterface – This contained the overlay elements of the GUI and managed their position and visibility, as well as the resources (fonts and images) used in their creation. This class inherited from HMD (Head Mounted Display), an abstract class used for creating GUI elements that are placed over the 3D view of the environment.

Environment – The contents of the 3D environment were constructed and controlled within this class. Built-in MOGRE features such as lighting, skyboxes (surrounding cube for ‘sky’ background) and fog were controlled here. The 3D models built in 3ds Max were loaded and updated from this class by instantiating the House, WeatherVane and WeatherGrid classes. Instances of the

WeatherSound and Ground classes were also created here.

WeatherSound – This class utilised a MOGRE add-on library for implementing audio effects in line with environmental changes.

Figure 4.4: Simplified UML Diagram.

(23)

16

4.5 3D Environment Design

The 3D environment was developed significantly during the implementation stage, however the layout of the environment and the overall aesthetic were defined during the design process. As can be seen from the storyboarding (see Fig. 4.2), the concept from the start was to have a house within a garden scene that would be subject to the weather conditions.

The design of the environment had to serve two purposes, it had to be aesthetically pleasing but it also had to contain objects that would assist in communicating the forecast. For example, to visualise the wind direction, objects were required within the scene that would in reality be moved by the wind’s force. At first it was thought that a tree (or multiple trees) would work for this purpose but with further consideration it became evident that trees swaying, or their leaves falling, in the direction of the wind was actually quite a subtle effect and so not particularly clear to the viewer.

The solution to this was to include a weather vane atop the house that would change direction with the wind; this was also easier to build from a modelling perspective. Furthermore, either the

environment or the GUI needed to contain an element that identified the orientation of the scene in order for any directional movement to have meaning. The final design solution to this was to include 3D letters set within the ground surrounding the house.

Practicalities such as these resulted in an iterative design process that developed throughout the implementation stage as unforeseen issues arose and new ideas were generated. The final layout design can be seen below (Fig. 4.5).

Figure 4.5: 3D environment layout design.

The overall aesthetic of the environment and the house also evolved during implementation although the theme was that of a home within a rural setting. The exact look of the building and

(24)

17 surroundings did change although an initial model produced for a poster shows an early idea for how it would look; see Figure 4.6 below (see Appendix B for the full poster).

Figure 4.6: Initial 3D model of environment (built and rendered in 3ds Max).

4.6 Graphical User Interface Design

There were two main aspects of the GUI; the information displayed relating to the forecast and the interactive buttons allowing the user to control the application.

It was decided to place the display information at the top of the screen. The current forecast

location, date and time of day were considered essential information to the user and so were placed centrally in a larger font size. Forecast condition information was supplementary to the 3D

visualisation and so not given as much prominence located in the top left of the screen. The fields that were selected to be included were condition (clear, rain, fog etc.), temperature, wind speed and direction and humidity. The condition and wind direction could have been deduced from the

visualisation whereas the wind speed, temperature and humidity could not. Temperature and humidity were included as they were identified as standard conventions within weather forecast displays during the research phase of the project.

The interactive elements of the GUI had to allow the user to complete all necessary actions to make full use of the application’s functions. The three key functions accessible to the user were: selecting the time within the defined forecast range, changing forecast location and changing the viewing angle to rotate around the house.

It was anticipated that time selection would be the most important and heavily used function by the user. This part of the GUI was engineered to provide the user with different options for navigating time, thereby catering for different user behaviours. An interactive time bar was devised that could

(25)

18 be operated by either clicking at any point in time on the bar to skip directly to that forecast time or by clicking a plus or minus one hour button to move in increments from the current time. In addition to this a play/pause button was included that would automatically step forward through time by one hour on set intervals of 1 second.

The other functions (location and rotate view) were developed further during implementation although their position was decided at this stage. It logically followed to have the change location menu at the top of the screen in line with the location display. As a result, with limited screen space remaining, the rotate view button was placed at the bottom of the screen to the right of the time bar.

Figure 4.7: Prototype mock-up of GUI layout.

A prototype mock-up of the GUI was produced in order to test its viability, see Figure 4.7 above.

During this design phase it was identified that there may be visibility issues related to the font colour used in the GUI. This was experimented with at implementation when the final environment colours were in place. It was accepted that a dynamic font colour that changed with the environment may be required, particularly as the environment would cycle through from bright daylight to night time darkness. The alternative was to have panels behind the GUI elements however this was considered unappealing as it would obscure the user’s view of the environment.

(26)

19

5. Implementation

The first phase of the implementation initially focused on constructing a stable 3D environment using MOGRE within Visual Studio. This involved creating much of the code structure described in section 4.4. In addition to the environment the other key module of code written at this stage was the weather forecast API call and data management.

Once this was done the focus shifted to building the 3D models within 3ds Max before importing them into the MOGRE engine format so that they could be utilised within the program. The models were then viewed within the MOGRE development environment, evaluated and, where necessary, refined within 3ds Max before being imported once again. The initial implementation of the GUI was then completed.

With the environment functional and preliminary versions of the models and the GUI in place, the final phase of the implementation began. This involved programming solutions to the day-night cycle, the various weather conditions and the audio effects. A key aspect to all of these challenges was to ensure that they could synchronise with the forecast input from the API as well as the user input through the GUI.

The implementation process is described in detail below.

5.1 Initial Program Setup

5.1.1 MOGRE environment

As stated in section 4.4, the starting point for the project was a pre-existing program created for a 3D computer game. This saved some time in setting up the initial MOGRE environment code structure although it did mean that the first task was to clear down all unwanted code and assets from the project. Once completed all that remained was a basic MOGRE generated 3D environment containing a surface floating in an open sky, see Figure 5.1 below.

Figure 5.1: Initial basic MOGRE generated 3D environment.

(27)

20 This basic scene was created using the MOGRE library of classes and methods. The MOGRE engine uses a system of scene management whereby all 3D renderable entities contained within the environment are attached to a scene node; this defines its location and orientation tracked relative to a root scene node. It is with this basic concept that the scene was built and at this stage the scene contained just a grass textured ground plane, a skybox to give a 360° panoramic skyline, basic lighting and a camera to control the viewing perspective.

Every aspect of the environment was later altered or replaced with new assets during the

implementation process. This scene did however provide a functioning environment within which to test the implementation of the program’s other components.

5.1.2 Weather Forecast API

The coding to collect and organise the weather forecast data was written at an early stage of the implementation due to its importance. It was necessary to establish a robust mechanism for this data feed and to clarify how the data would be managed as it would be central to the application’s functionality.

The Weather Underground API had been identified during the research phase of the project as appropriate for the application’s needs. The first step to implement this was to register the application on the Weather Underground developer site in order to obtain a key to access the API.

A tutorial was found online that provided sample code for retrieving data from the Weather Underground API in Extensible Markup Language (XML) format (Toepke, 2013). This sample code needed to be adapted, it was originally written to retrieve only the current forecast for 5 locations and display selected text forecast information in the Visual Studio console. This was changed to retrieve the 10 day hourly forecast (240 hours) and organise that data in what are known as XmlNodeLists. This method allowed for the hourly forecast data to be held in chronologically

ordered indexed lists for each data field retrieved. The below code excerpt (Fig. 5.2) shows the parse method from the WeatherForecast class that performed the translation from a string in XML format into XmlNodeLists. Specific paths (or nodes) were searched for within the XML document, with all instances placed into the relevant XmlNodeList in the order they were found (i.e. chronologically).

Figure 5.2: XmlNodeList code excerpt.

(28)

21 As can be seen in Figure 5.2 (above), it was established that 12 separate data fields would be

collected from the API for each hourly forecast; these were: hour of the day, AM/PM format time, day of the week, day of the month, month, year, temperature, condition, forecast code, wind direction, wind speed, humidity.

The WeatherForecast class also contained a number of ‘get’ methods to allow for the distribution of the forecast data to other classes within the program. The XmlNodeList approach allowed for a clear and consistent method of accessing forecast data for a specified period. Figure 5.3 (below), shows a

‘get’ method that returns the “i^th” wind direction string from the windDirection XmlNodeList. This will be the wind direction “i” hours from the current (0) time.

Figure 5.3: getWindDirection code excerpt.

5.2 3D Environment Build

5.2.1 Modelling & Texturing

All components of the 3D environment except for the ground and the surrounding sky box were created within 3ds Max. This included the house and front path, lamp post, weather vane and the four orientation letters.

The frame of the house was constructed initially from a primitive box shape that was converted into an editable poly. From this basic polygonal mesh the frame structure was formed by extrusion, polygon-level editing and edge bridging techniques.

Figure 5.4: 3ds Max polygon editing for house frame creation. Clockwise from top left: polygon extrusion technique for primary house frame setup, polygon deletion for window space, completed house frame, edge bridging technique to cap inside edge of window space.

(29)

22 With the frame complete, other items such as the roof, doors, window frames, lamp post and paving stones were created using similar techniques. The models were refined during the implementation with earlier versions having a significantly higher polygon count. The aim was to produce models with a good level of detail and yet as simple in polygonal structure as possible to limit the strain put on the GPU. A lot of visual detail was added afterwards through the use of textures.

The interior of the building was visible through the windows and so had to be modelled in the same way. Floors, walls and ceilings were created but for this version of the application it was decided to keep the internal spaces empty apart from a staircase connecting the floors. Although a ‘fully furnished’ house would have been preferable, this decision was made to keep the overall polygon count of the models down. The staircase was not manually created but in fact came from the 3ds Max asset library that contained a selection of customisable commonly modelled objects. The asset library also contained window frames although these were considered to be over-engineered and so a lower polygon count alternative was manually created.

The house and related objects were then textured within 3ds Max (see Texture Reference List at end, textures 1-8). This process enhanced the appearance of the models considerably. A number of the objects were very simply textured with a single colour that required minimal work; this included the window frames, drain pipes and lamp post. The more complex items such as the brick walls, wooden floors and doors were textured using bitmap images that were sourced online and edited within Photoshop. These images were then mapped onto the polygonal meshes using the UVW Unwrap modifier within 3ds Max. This technique allowed for complete control of how an image was mapped onto the surface of a mesh with free transform editing to vertex level.

Figure 5.5: Original brick wall image sourced online (left) and edited version with texture map for the house frame polygon mesh in 3ds Max (right).

The letters surrounding the house were quickly constructed using 3ds Max text splines, converting them into editable polys and then extruding the letter shaped polygons to produce 3 dimensional

‘N’, ‘E’, ‘S’ and ‘W’ letters. The top polygon face was then textured with a grass bitmap image that was also used within MOGRE for the ground surface.

The house and surrounding objects were then ready to be exported into a format compatible with MOGRE. Figure 5.6 (below) shows the fully textured models within the 3ds Max software.

(30)

23

Figure 5.6: Fully textured model of the house and surrounding items.

The weather vane was created in 3ds Max separately and imported as a separate entity into MOGRE as it needed to be rotated independently in sync with the wind direction. The model was kept very simple with the cockerel detail achieved using a partially opaque texture map, thereby keeping the polygon count down to a minimum.

5.2.2 Export to MOGRE

Exporting the models into MOGRE compatible format (a .mesh file) required the installation of a plugin for 3ds Max that could perform the conversion. There were various options online but after some background research the OgreMax Scene Exporter plugin (AND Entertainment LLC, 2014) was installed, a software download that was free for non-commercial use. This provided integrated export functionality within 3ds Max to the .mesh format.

The models could be exported as a group or individually, so all of the static objects (see Fig. 5.6) were exported as one. The export produced a .mesh file containing, amongst other things, the vertex coordinates and a .material file containing the bitmap image references and texture coordinates.

The two files were then placed within the Visual Studio project directory as required.

With the files in place they could be referred to within the code and placed in the scene in a similar fashion to the ground plane. The models were then viewed within the MOGRE 3D environment. The main checks carried out were whether they appeared proportionally and relatively correct in terms of size and whether the textures appeared as expected. Some refinements to scale were made in the program code itself and some changes to textures were made back in 3ds Max before re-exporting the models.

Another check carried out was how the model’s presence within the MOGRE environment affected the frame rate that the program could operate at. This is where simplification of the models showed tangible results. One example of model simplification identified at this stage was the removal of glass panes within the window frames. Glass panes were included in the house model at the beginning to give a partially transparent tinted effect with some reflection. It was discovered that the demands this put on the GPU was slowing down frame rate by roughly 500 frames per second

(31)

24 (or 20%) and so the decision was made to take out the glass panes. Although a rather subtle yet pleasing visual effect was lost, the benefit to performance was thought to be comparatively greater.

5.3 GUI Build

As previously stated, the GUI could be split into two different areas of development; the display information elements and the interactive user input elements. Both areas utilised the overlay

management system included with MOGRE. This allowed for the arrangement of elements that were visible on top of the 3D environment display. These elements were then populated with text or images and dynamically controlled with update methods and functions such as adjusting visibility or colour; this code was contained in the WWInterface class that was instantiated within the

WeatherWorld class.

5.3.1 Forecast Information Display

The GUI design laid out what information would be displayed and where; forecast information top left and location, date and time top centre. These elements were located using the MOGRE overlay management system’s standard methods and contained locating pixel coordinates that were relative to the display window so that they would appear correctly on screens of any resolution.

The information displayed was a collection of strings sourced, originally, from the weather forecast data. This data was contained within instances of the WeatherForecast class created in the

WeatherWorld class. The information displayed was to be only that of the currently selected forecast in terms of location and time. In order to display the correct forecast information, the mechanism involving the ProgramData class was utilised. This can best be explained with a working illustration as below.

The ProgramData class contained a field named currentForecastLocation.

The single instance of the ProgramData class created within the WeatherWorld class was passed to the WWInterface class via its constructor.

If the forecast location changed at any point then the currentForecastAssignment method within the WeatherWorld class assigned a new value to the programData.currentForecastLocation variable.

…and this was updated within the relevant overlay element (locationText) in the WWInterface Update method, thereby changing the GUI display.

(32)

25 5.3.2 Interactive Interface Elements

The interactive elements of the interface included the clickable time bar near the bottom of the screen, the play/pause button below the time bar, the rotate view button and the change location menu.

A consistent theme in terms of form and colour was maintained throughout the GUI. A clean and simple design was developed in blue tones with some semi-transparent sections that would become opaque when hovered over or pressed. This theme was visible in all conditions and allowed for clear feedback to the user but was also relatively discreet when inactive and so would not obstruct the user’s view of the environment unnecessarily.

There were two stages to the implementation of these parts of the GUI. Firstly the different visual elements had to be created in Photoshop and all of these required multiple versions to allow for the appearance of, say, a button to change when it was hovered over or pressed. Figure 5.7 below shows 3 different states of the time bar that were created.

Figure 5.7: Multiple versions of the time bar GUI element. From top to bottom: state when inactive, state when mouse hovered over plus one hour arrow button, state when plus one hour arrow button is pressed.

Secondly, code needed to be written so that the program could track the movement and actions of the user’s mouse to identify when the cursor was hovered over elements of the GUI and when the mouse was clicked. Tracking the actions of the user was handled in the InputsManager class. The ProcessInput method monitored the coordinates of the mouse cursor and when the coordinates were within certain regions of the window then Boolean fields of the ProgramData class were changed from false to true and back to false when outside of those regions. The OnMousePressed and OnMouseReleased methods combined the mouse’s click events with these Boolean conditions to trigger actions for the GUI buttons only if the cursor was over that button and the mouse had been clicked. This process allowed for advanced interaction within the GUI and so offered clear feedback to the user. Figure 5.8 below shows different states of the time bar subject to different user interactions.

Figure 5.8: Time bar interactions. From left to right: time bar semi-transparent when inactive, time bar internal indicator opaque on hover, time bar end arrow opaque on hover, time end arrow dark blue on press.

(33)

26 The code that linked the GUI interactions to changes in the environment was also contained in the InputsManager class. So, for example, if the plus one hour button was pressed then the

programData.forecastTime integer variable was increased by one.

All parts of the GUI were created in a similar fashion but each had unique features specific to its function, these are detailed below.

Time bar – This consisted of a clickable bar that would allow for instant ‘jumping’ from any time during the 10 day forecast to another, as well as plus and minus one hour buttons on either end.

This interacted exclusively with the programData.forecastTime integer variable by either adding or subtracting increments of one, or by setting the variable to a new value depending on where on the time bar the mouse was clicked.

Play/Pause button – A simple circular button that switched between a play symbol and a pause symbol. This functioned by increasing the programData.forecastTime integer variable by one every 1,000 milliseconds and so effectively stepped through time in an automated fashion when play was pressed until pause was pressed. This was implemented using a timer and a tick event handler within the InputsManager class; see Figure 5.9 below for code excerpt.

Figure 5.9: Timer code excerpt.

Rotate view button – A simple square button containing a rotating arrow symbol that altered in contrast when hovered over. This functioned by switching the programData.camRotate Boolean variable between true and false. If true, then the scene node that the camera was attached to rotated around the origin of the scene (where the house was located). If false, the rotation stopped.

Change location menu – It was decided during implementation to keep the change location options relatively simple. There was an option to go down the route of allowing the user to type in any location using the keyboard and then display the forecast for that location. This was a possibility, and would certainly be a feature of a further developed solution, but was considered unnecessary considering the development time required for this first version of the application. In place of this, a drop down menu of three pre-set locations was implemented (see Fig. 5.10 below, top right of screen). This menu was created to only be visible once the square location button in the very top right of the window had been clicked and hidden with another click. The three drop down buttons altered the programData.currentForecastLocation variable accordingly.

(34)

27 Figure 5.10 (below) shows the final GUI design implemented within the working application. Some minor tweaks to the GUI code were made at the end of the implementation process (see section 5.5).

Figure 5.10: Full GUI implementation (please note, the frame rate panel in the bottom left of the screen is a part of the MOGRE framework).

5.4 Advanced 3D Programming

With the overall program development at an advanced stage, it was the ideal point at which to fully implement the day-night cycle and weather condition simulations. The methods, detailed below, were developed throughout the implementation although only with all the key components (code structure, 3D environment, API feed and GUI) in place could they be finalised. These simulations were crucial to the success of the application and its core goal of communicating the weather forecast.

The main weather conditions had been specified earlier on in the project (see section 2.3) and were identified within the program using the weather API forecast code field. Some of these conditions held shared attributes that related to the lighting and the appearance of the sky; for example, overcast sky for snow and storm conditions. With this in mind, the day-night cycle was approached first.

5.4.1 Day-Night Cycle

Since the application would provide a 10 day hourly forecast to the user it was essential that the 24 hour cycle from night into day and back again was visually realised. It was determined that this could be achieved using two features of the MOGRE framework; the skybox and the lighting.

Using MOGRE it was possible to implement a skybox with just one line of code containing the SetSkyBox method. One of the parameters of this method was a reference to a texture script that held a further reference to the images that made up the ‘sky’ background (6 images, one for each