Wind

The primary indicator for wind direction was the weather vane situated on the top of the house. As previously stated, the weather vane 3D model was imported into MOGRE on its own so that it could be manipulated independently.

The weather vane needed to rotate around its central point (its mast). To achieve this, its scene node was attached to a control node that was in turn attached to the root scene node. The control node allowed for the weather vane model’s pivot point to be centred. With this adjustment made, the control node was rotated in line with the wind direction sourced from the weather forecast and accessed through the ProgramData class. An ‘if’ statement was used to set the orientation

dependent upon the wind direction string; for example, the zero point was east so if the wind direction was north (“N”) then the orientation was set to 90° counter clockwise or (0.707, 0, -0.707, 0) in quaternion units.

30 5.4.3 Rain & Snow

The rain and snow conditions were viewed as extremely important conditions to get aesthetically correct; rain being a very common condition and snow being visually powerful. The two were grouped as they were created within the same mechanism; this logically follows from nature as they are both forms of precipitation.

The research carried out and detailed in section 2.3 informed the method used here. An article on fxguide.com (Seymour, 2013) referred to a rain simulation technique used in games whereby multiple conical layers of animated semi-transparent raindrop textures were placed in fixed positions progressively far away from the player’s viewport. The multiple layers created a sense of depth and contained different textures to avoid any noticeable uniformity in the rainfall.

A similar, yet distinct, technique was developed for this application. Instead of the layers being fixed relative to the viewport, they were fixed relative to the scene. This would create an effect similar to a snow globe with the weather conditions surrounding the house. And instead of conical layers, the layers were created as planes set out in a grid formation. This method was a result of

experimentation and was found to give a realistic and visually pleasing impression.

The grid formation was a particular point of experimentation with the final version being a slanted diamond-shaped grid of 15 planes on one axis and 15 on the other; the grids were randomly offset from each other to prevent uniformity. This grid produced a good sense of depth to the weather conditions and facilitated a simpler way of adding directionality to the rain or snow in line with the wind (the same method of rotation was used as with the weather vane). Figure 5.12 shows different versions of the grids that were built in 3ds Max and then imported into MOGRE format.

Figure 5.13: Snow/rain weather grids that were produced during the experimentation stage. Clockwise from top left: a cloud like structure of circular planes, a vertical and horizontal plane box grid, the final diamond-shaped grid of 30 planes, a square grid of 60 planes.

Each plane had an animated texture seamlessly scrolling along its surface. There was a texture for rain and a separate one for snow; both created in Photoshop. The scripts allowed for refinement of

31 the scrolling animations so that the rainfall appeared to fall rapidly as opposed to the snow’s more floating, gradual descent.

The implementation at this stage meant that the grids appeared when rain or snow was forecast with the relevant texture assigned. Although this gave a reasonable appearance, it meant that the conditions instantly appeared in place whereas a more gradual build up was desired. The solution to this was to have the entire grid appear up above the house and then move vertically downwards with a new grid appearing above the current one at an appropriate moment to ensure continuous precipitation until it stopped and then a gradual end to the condition would appear. Too many of these grids being present in the scene resulted in the program slowing and so a solution was found.

The grids were held in a list that could not contain any more than 2 objects, once a grid fell below the ground surface it was disposed of and so a new grid could be created up in the sky and begin to fall. This solved the slowdown problem.

Figure 5.14: Rainfall conditions (top left & right) and snow conditions (bottom left& right) at different times of day.

5.4.4 Fog

The MOGRE framework contained a method for implementing and altering fog conditions. The SetFog method allowed for customisation of the fog colour and density. When the scene was loaded the fog would be set at an imperceptibly low density that would be increased if fog conditions were forecast.

There was a problem with the MOGRE fog effect that meant it had the desired effect on the appearance of the 3D models within the scene but the skybox remained visible. This created an unrealistic appearance and so it was necessary to produce another set of skyboxes specifically for fog conditions. This was not overly time consuming as the skybox textures were plain colours with no cloud or horizon details, just different tones for different times of day in line with the colour

32 filters applied to the previously implemented skyboxes. The colour of the fog was then set to match the ambient light and skybox conditions. This produced a realistic effect, see Figure 5.15 below.

Figure 5.15: Morning fog conditions.

5.4.5 Thunderstorm

Thunderstorm conditions consisted of the same elements as rain but with the addition of lightning and sound effects (see section 5.4.6 below). A realistic lightning effect required intermittent flashes that would light the entire environment for just a moment.

The flash itself consisted of two elements. Firstly, the ambient light would be set as white to light up all the objects in the scene apart from the skybox. Secondly, in order to give the effect of the skybox being lit up, a compositor was needed. A compositor can be used to apply an effect to the viewport itself and so affects the whole display screen. The compositor used here utilised a shader to multiply all the colour RGB values in the viewport by three and so created an ultra-bright screen effect for the lightning flash.

In order to instigate these flashes on an intermittent basis a random number between 1 and 60 was generated every frame that thunderstorm conditions were present. Each time that random number equalled 60 there would be a flash and so there was a 1 in 60 chance of a lightning flash each frame, this produced a realistically unpredictable pattern to the lightning flashes.

5.4.6 Audio Effects

The audio effects were implemented using an add-on plugin to MOGRE. There was a small selection of audio plugins available, the one chosen was irrKlang (Ambiera e.U., 2014) as it offered all the required features for basic sound integration and was free for commercial use.

A WeatherSound class was created to hold all the required coding; this would be instantiated within the Environment class. The basic function of the class was to load the sounds used in the application

33 on launch and then pause them until the requisite weather condition was present at which point they were played; all weather sounds being continuous audio loops.

The audio elements included were as follows: ambient background nature sounds for the day time, ambient background nature sounds for the night time, rain sounds, thunderstorm sounds and wind howling sounds. One of the two ambient sounds would always be heard with the others played simultaneously in line with the forecast conditions. The wind sound was programmed to become audible when the wind speed exceeded 15 mph and to get progressively louder until reaching full volume at 74 mph; this covered wind conditions from moderate breeze up to hurricane as per the Beaufort wind force scale (Met Office, 2014a).

The sound files used were created using an online sound mixer (naturesoundsfor.me, 2014). With this tool it was possible to create a customised soundscape from a selection of nature sounds (e.g.

birdsong or rainfall) that was then compiled and exported to produce an audio file of a specified length.

5.5 Final Code Refinements

Once the weather simulations and all visual and sonic aspects of the environment were developed then all of the code was reviewed and functionality tested (see chapter 6). As a result, some final tweaks were made to the program.

5.5.1 GUI Text Colour

As had been identified during the design process, there was an issue with the GUI text not always appearing clearly due to a lack of contrast with the changing 3D environment behind it. It was found that with the use of either white or black text that the information was readable in all conditions. An

‘if’ statement was included within the WWInterface class’s Update method to change the text colour in response to the current conditions. The text was kept white unless there was snow, daytime cloud or daytime fog (see Fig. 5.16 below).

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

5.5.2 Scenario Change Trigger

As more features were added to the program there became a noticeable slowdown in frame rate.

This was reduced through the use of a scenario change trigger. This was a Boolean parameter of the ProgramData class that was changed from false to true when any variable that affected the

environment was altered and only when this parameter was true did the program’s update method read the code associated to changing the environment. This implanted intermediary step prevented the program from having to update all elements of the scene each frame and resulted in an

improvement to frame rate and so a more visually smooth appearance.

34

6. Testing

Both during and at the end of the implementation, testing was carried on the program to ensure that the system was producing the expected outcomes. This was approached by checking the functionality and the program’s response to inputs after each module was added to the program.

The GUI implementation required rigorous testing to ensure that the interactive elements were responding to user inputs in the correct manner. The hover and click regions for each button needed to be checked for accuracy, and also that such actions resulted in the expected visual feedback to the user. Once the program was completed then each button was re-checked to confirm that the user’s actions were altering the program’s status as intended.

The InputsManager class was set up so that input parameters to the environment could be controlled directly using the keyboard. This allowed for time-efficient and controlled testing of the inputs to the system and how they were being processed. A key example of this was the forecast codes that could be stepped through one by one in order to check that the conditions within the environment, and the audio, responded correctly and produced the appropriate effect.

As stated and described in section 5.5, some adjustments were made to the program as a result of this testing procedure.

35

7. Evaluation

A continuous process of evaluation and feedback into the design was carried out throughout the implementation. Once the full working prototype was completed and was proven to function as per the design, user tests were performed in order to evaluate the usability of the application. These tests also provided an objective view of the application as a whole.

7.1 User Test

7.1.1 Preparations

In order to conduct the user test, test materials were produced and submitted for ethical review by the University of Sussex School of Engineering and Informatics School Research Ethics Officer. A participant consent form, participant information sheet and recruitment email were submitted and approved (see Appendices C-E).

Participants were recruited via email and also personal approach with information sheets handed out. In total 7 participants were recruited and appointments arranged to take part in the study on the University of Sussex campus.

7.1.2 Testing

The test involved a one on one session with the tester and the participant lasting roughly 20 minutes (see Appendix F for the tester guidance note sheet). It began with the participant given 4 minutes to use the application unguided by the tester. The tester observed the participant’s actions and took notes. This was done to gain perspective on the usability of the application for a first time user and, particularly, how intuitive the interface was.

This was followed by a guided navigation through the application’s main features and a

demonstration of all weather conditions. This was done to ensure that the participant experienced all of the application’s features and also to highlight what they had missed in order to discover why they may have missed certain features or functions.

Finally, a semi-structured interview was carried out with notes taken by the tester. This consisted of 6 questions aimed at exploring the participant’s opinion on different aspects of the application. The interview was kept reasonably informal and open to explore areas not covered by the questions.

This was done to gain as much reflection from the participant on their experience using the application.

7.1.3 User Feedback

The tests collected a good range of feedback with some consistent themes arising. Although a larger group of participants would have produced a more robust result, this was a good starting point for further development.

The positive feedback was largely centred on the appearance of the environment. In general the participants liked the 3D environment and the ability to rotate around the scene using the rotate button. Almost all participants commented that they liked how the lights within the house and the lamp post turned on at night.

Although the majority thought that the day-night visual progression was done well, three participants did suggest making the night time brighter so that the environment and weather

36 conditions could be seen more clearly. It was also commented that the dusk and dawn conditions appeared too yellow in colour.

The weather simulations were generally considered successful in communicating the weather forecast. Of the various conditions the appearance of the fog, lightning and snow received the most positive mentions. Four participants said that they hadn’t noticed the weather vane changing with the wind direction when this was described to them in the guided navigation. All participants made positive comments regarding the sound effects and considered that a good feature.

The GUI overall received positive comments although not all users noticed that the plus/minus one hour buttons at each end of the time bar were clickable during the unguided section of the test. One participant suggested making these larger with clearer text describing their function. Another user thought that the forecast location, date and time text should be larger and more prominent on the screen.

A feature that consistently received negative comments was the play button used to step forward in time on set intervals of one second. Although the feature was liked, it was considered by all but one of the participants as too quick. It was also thought to be particularly confusing and hard to interpret the forecast when the time was progressing and the camera was also rotating around the scene.

None of the present features were considered unnecessary and ripe for removal, however the participants made several suggestions of features that they would like to see added. The suggested features included:

- ability to type in any forecast location

- ability to choose or customise the house in the scene - additional items in the scene (people, trees, garden, car) - a more realistic landscape

- alternate camera angles or ability to ‘walkthrough’ the scene

The feedback gained from the user test would be used to refine the application’s functionality and inform possible future development of the application; this is discussed in the next, concluding, chapter.

The feedback gained from the user test provided useful information for potential refinements to the application’s functionality and possible future development of the application; this is discussed in the next chapter (section 8.3).

37

8. Conclusion

8.1 Project Review

The application successfully met all of the requirements laid out at the start of the project. In line with the proposal, the application took as input a weather forecast data feed and translated it into a 3D environment visualisation. As was the aim of the project, the result served as a proof of concept that such an application could be created and could function in the desired manner. One of the key challenges identified at the start was to produce high quality graphics that could be manipulated in real-time and communicate the forecast effectively; this was achieved.

8.2 Limitations

If there was one limitation of the project it was the issue of how the medium of a 3D visualisation compared up against the traditional, and much simpler, text and icon based forecasts present across all media (newspapers, TV, online etc.). One aspect of this was the absolute nature of the

visualisation. If the forecast was ‘chance of showers’ then the visualisation had to show an environment with rain falling, it was not possible to convey the concept of chance or probability solely within the 3D environment. Of course the application solved this by supplementing the visualisation with text forecast information, however if this was relied on too heavily then to some extent the visualisation could be viewed as redundant or merely an aesthetic embellishment. It should however be acknowledged that this application aimed to provide a novel way of viewing weather forecast information and so the aim was not simply to provide information but to do so in an engaging and entertaining manner. The feedback from the user test suggested that this had been achieved.

Overall the design and implementation of the application was without fault and produced the desired result within the timeframe allowed. There was, however, one significant element of the project that could have been approached differently and perhaps should have been. This was the selection of the 3D engine used to power the application’s 3D environment. The MOGRE system certainly performed adequately and the flexibility offered by the available add-on libraries, as identified during the software selection process, allowed for a richly featured end product. Where it fell short was in terms of graphical power. Some elements of the implementation were restricted by the limits of the engine’s graphical power, one example being the rain and snow that required much experimentation to deliver a satisfactory solution that didn’t slowdown the performance excessively.

Although the main reason for choosing MOGRE (past experience saving learning time) was certainly justified and probably unavoidable considering the time limits of the project, one of the alternatives may well have been capable of creating a more graphically impressive end product.

8.3 Future Development

Even though the application met all of the project’s requirements, there was great scope left for further development. Potential additional features were identified throughout the implementation process as well as those suggested by users during the user test. Some features, such as the ability to type in any desired location and have its forecast displayed, were not included due to time

constraints but would certainly be implemented in a commercially released version. Accurate

constraints but would certainly be implemented in a commercially released version. Accurate