• No results found

5. Implementation

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.

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.

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 “ith” 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.

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.

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

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.

Related documents