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.

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.

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

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).