Visualisation of Tsunami Simulations Adam Wilde
BSc (Hons) Computing (Ind) (2005/2006)
The candidate confirms that the work submitted is their own and the appropriate credit has been given where reference has been made to the work of others. I understand that failure to attribute material which is obtained from another source may be considered as plagiarism. (Signature of student) _______________________________
Summary
This project focuses on the use of 3D visualisation and interaction techniques with the aim of
developing informative, flexible, efficient and attractive approaches to displaying water wave
simulations. The water wave simulations will be generated in binary data form, using the existing 2D
numerical wave model OTT-2D but will be transformed into a full screen 3D visualisation that can be
used to explore areas of interest on the water surface and bed topography, whilst simultaneously
displaying water velocity and producing animations of the wave run-up.
i
Acknowledgements To my supervisor, Matthew Hubbard, for explaining the structure of the OTT-2D data files (on more
than one occasion) and also for offering alternative approaches when I felt out of my ‘depth’. To
Leroy, for his time and C++ expertise. My parents, for desperately trying to understand the technical
aspects of the project and to my girlfriend, for keeping me alive when I didn’t have time to cook for
myself.
ii
Table of Contents
Chapter 1 Project Introduction 1.1 Problem Statement …………………………………………………………..… 1 1.2 Objectives ………………………………………………………….………….. 1 1.3 Minimum Requirements……………………………………………………….. 2 1.4 Other Areas to Consider ………………………………………………………. 2 1.5 Deliverables ……………………………………………………………..…….. 3 1.6 Relevance to Degree Programme ……………………………………….…….. 3 1.7 Background Reading ………………………………………………..……….... 4 1.7.1 Existing 3D Graphic Languages and Visualisation Environments … 4 1.7.2 Spatial Data Structures ……………………………………………... 7 1.7.3 Adaptive Mesh Refinement ………………………………………… 10 1.7.4 Existing AMR Visualisation Techniques …………………………... 12 1.7.5 Human-Computer Interactions within 2D/3D Environments ……… 15 1.8 OTT-2D Overview ……………………………………………………………. 16 Chapter 2 Design ………………………………………………………………………… 18 2.1 Requirements . ………………………………………………………………… 18 2.1.1 Ability to Recognise and Handle OTT-2D Output Files …………… 18
2.1.2 Facilitate Internal Storage of Simulation Data Values ……………… 19 2.1.3 Generate Accurate Representations of Wave Data in Mesh Form….. 20 2.1.4 Control Simulation Timing …………………………………………. 21 2.1.5 Allow Simulation Manipulation ………………………………….… 21 2.1.6 Support Cross Platform Operation…………………………………... 22 2.2 Preliminary Design…………………………………………………….……….. 22 2.2.1 Vectors as Dynamic Storage Elements……………………………… 22 2.2.2 Using a Quadtree for Mesh Joining at Different Levels…………….. 23 2.2.3 Lighting and Normals………………………………………………... 24 2.2.4 Creating Timeframes………………………………………………… 25 2.2.5 Using the GLUI Toolkit for Creating Interactive Controls………….. 26 2.3 Hardware Requirements………………………………………………………… 26 2.4 Software Requirements…………………………………………………………. 27
iii
Chapter 3 Implementation…………………………………………………………….… 28 3.1 Methodology………………………………………………………………..…. 28 3.2 Development Plan……………………………………….…………………….. 28 3.3 Development Phases…………………………………………………………… 29 3.4 Description of Methods………………………………………………………... 33 3.5 Solutions to Problems Encountered……………………………………………. 36 3.5.1 Vertex Arrays………………………………………………..………. 36 3.5.2 Vertex Buffer Objects………………………………………….……. 37 3.5.3 Unstructured vs. Structured Output Files………………….…….…… 38 3.5.4 Handling the Unstructured Data Format. …………………………… 38 3.5.5 Using GLUT for Timing. ……………………………..………….…. 39 Chapter 4 Evaluation……………………………………………………………………... 40 4.1 Introduction…………………………………………………………….………. 40
4.2 Evaluation Against Minimum Requirements…………….……….……………. 40 4.3 Heuristic Evaluation……………………………………………………………. 42 4.4 Formative Evaluation. …………………………………………………………. 45 4.5 End User Evaluation……………………………………………………………. 45 4.6 Functionality versus Efficiency. ……………………………….………………. 47 Chapter 5 Conclusion…………………………………………………………..…………. 49 5.1 Successes…………………………………………………………………….…. 49 5.2 Failures…………………………………………………………………….……. 49 5.3 Future Enhancement Possibilities………………………………………………. 49 5.4 Evaluation of Decisions Made……………………………………………….…. 50 5.5 Overall Methodology Evaluation………………………………………………. 50 References………………………………………………………………………………….……. 51 Accompanying Material……………………………………………………..…………………. 54 Appendices………………………………………………………………………………………. 55 Appendix A Personal Reflection…………………………………………..………. 55 Appendix B Initial and Final Project Plan…………………………………………. 57 Appendix C Test Plan…………………………………………………………..…. 59 Appendix D Visualisation User Manual…………………………..………………. 60 Appendix E GLUI Feature List……………………………………………………. 61
iv
1 Project Introduction
1.1 Problem Statement
The aim of the project is to construct and use suitable data structures and algorithms to generate 3D
visualisations of the output from an existing numerical water wave model OTT-2D written in Fortran
90 Code. The existing code generates simple but adaptive simulations of water waves in the form of
numeric data output files; however the aim of the project is to produce an efficient and clear 3D
representation of the flow of water alongside the corresponding bed topography. The visualisations
should be informative, flexible, efficient and attractive and have the ability to run on various
platforms. It should make good use of HCI techniques to provide the user with simple, straight-
forward, yet powerful methods of manipulating the viewpoint and progress of the simulation.
1.2 Objectives
The current 2D numerical model provides accurate simulations of wave transformation, run-up,
overtopping and regeneration. The result of the simulation is a series of data files, containing arrays of
water depth, height of sea bed and flow velocity at each grid point throughout the period of the
simulation. The simulation can run across grids of various sizes and generate several finer scale grids
of varying range using an adaptive mesh refinement technique (AMR). The AMR allows for a high
level of efficiency, while providing greater detail (more points of recordable data) and increased
model adaptability, as the overlaid finer meshes are only applied to parts of the simulation that require
higher levels of resolution (such as a region of moving shoreline). While the numerical wave model
provides very accurate output data it requires a suitable form of visualisation for the end user. The
objectives of the project are therefore, to investigate appropriate techniques for visualising the
numerical wave model data in a 3D environment and allow several methods for manipulating and
controlling the 3D representation. The objectives of this project are not to explore the means by which
AMR techniques should be developed, but rather how AMR data scenarios can and should be
effectively visualised.
1
1.3 Minimum Requirements
The requirements below define the minimum that must be produced in order to deliver a solution to
the problem:
Produce a method of processing and storing wave run-up data from external data files
Produce an algorithm to generate efficient and clear step by step animations of the wave
run up
Employ AMR within the 3D visualisation of the wave and bed topography
Employ techniques to manipulate the 3D wave visualisation such as
zoom/pan/rotate/colouring
Regular feedback from the author of the numerical wave model will result in a 3D visualisation that is
tailored exactly to the author’s requirements and any further enhancements or modifications can be
made as are appropriate.
1.4 Other Areas to Consider
Once minimum requirements have been met, their will be further scope to add:
The ability to display flow characteristic calculations (velocity, height, etc.) at any given
point on the water surface
The functionality to load a selection of bed topography files, to change/enhance the
animation of the wave run-up
The ability to control animation speed, as well as add support for pause/fast forward and
rewind
The ability to control the appearance of the mesh, with choices of wireframe surface,
monotone or multicoloured (dependent on wave height/velocity)
Incorporate use of NVIDIA Cg rendering techniques to speed up simulation/visualisation.
(Only available for recent graphics cards; DirectX 9.0c compatible)
2
1.5 Deliverables
Final project deliverables will be:
Final solution in the form of one or more pieces of code and all necessary libraries
required to run the code and visualisation
Setup and operating instructions for the visualisation
1.6 Relevance to Degree Programme
This project will span a wide selection of topics that have been covered in university modules
including theories studied in lectures and practical skills learnt during coursework assignments. The
project will look mainly towards the computer graphics modules studied in the second and third years
but will also cover human computer interaction techniques from the GI11 and GI32 modules, software
methodology and management from the SE22 module and mathematical/programming experience
gained from the MA12, SO13 and SE21 modules.
3
4
1.7 Background Reading
1.7.1 Existing 3D Graphical Languages and Visualisation Environments
The choices of appropriate graphical languages and visualisation packages for this project are heavily
dependent on the platform and applications already available across the Leeds SoC computer network.
With this in mind, viable options are the MathWorks Inc. Matlab package, Iris Explorer and OpenGL.
Matlab is a data manipulation environment and a core programming language that includes a suite of
analytical tools and visualisation techniques, and allows for the use of existing functions and user-
defined programs. It provides an interface to allow matrix manipulation, algorithm implementation
and user interfaces as well as many other functions and can run across a wide range of operating
systems. It is a proprietary piece of software costing as much as $2000 per license for commercial use
[MathWorks, 2006].
Iris Explorer is currently developed and released through the software house Numerical Algorithms
Group (NAG). It was originally designed and developed by SGI, the people responsible for OpenGL
and runs on a collection of OpenGL, Open Inventor and ImageVision libraries as well as NAG’s own
numerical libraries. The aim of Iris Explorer is to provide a powerful visual programming
environment for 3D data visualisation, animation and manipulation. Visualisations are built up
through the selection of existing modules within the application. This removes the requirement for
any coding, although custom modules can be built in the FORTRAN or C languages. It is currently
available across a large number of platforms such as Microsoft Windows and Linux, however the cost
of purchasing the software is approximately £900 (for academic purposes) [NAG, 2006].
OpenGL is an open specification 3D graphics and modelling library that is extremely portable and
very fast to implement [Wright, 2000]. It offers an application program interface (API) for defining
2D and 3D objects rather than being an actual programming language and must therefore be used in
conjunction with a programming language such as c or C++. Initially developed by Silicon Graphics,
it allows any computer user to download the required libraries and create an application that will run
cross platform providing the user has an OpenGL specification graphics card. The majority of this off
the shelf hardware has been OpenGL compliant for a number of years, as end users have strived for
business applications and games that make use of 3D graphics [Wright, 2000]. It is widely used in
CAD, virtual reality, scientific visualisation, information visualisation and video game development
[SGI, 2006].
A comparison of the Matlab, Iris Explorer and OpenGL software follows:
Yes
OpenGL Matlab Iris Explorer
Available in SOC Yes Yes
Prior Experience No – therefore steep learning
curve
No – therefore steep learning curve, although Iris Explorer does implement OpenGL so some
features will be familiar Yes - GI21 and GI31 computing modules.
Cost to install outside of the SOC
$100 academic license, $2000 commercial use [MathWorks,
2006]. Therefore costly to install outside of SOC
Approximately £900 for academic purposes [NAG, 2006]
End users are free from licensing [SGI, 2006]. Easily available to anyone using any platform.
Cross Platform Supported on Linux, Mac OSX,
Solaris and Windows [MathWorks, 2006].
Supported on Apple Mac, UNIX, IBM RISC, Linux, Windows, Solaris and Silicon Graphics IRIX although it is only available on the SOC
Linux system [NAG, 2006].
Supported on UNIX is standard on Windows 95/98/2000/NT and MacOS PC. OpenGL runs on every major operating system including Mac OS, OS/2, UNIX, Windows 95/98,
Windows 2000, Windows NT, Linux, OPENStep, and BeOS. It is possible to implement OpenGL in Ada, C, C++, Fortran,
Python, Perl and Java [SGI, 2006].
Mouse and keyboard functionality is offered by the GLUT libraries and 3D party toolkits offer screen decoration in the
form of buttons, sliders, arcballs, checkboxes etc.
Visualisation Features
Colour control, scaling, rotation and timing
Colour control, scaling, rotation and timing
Almost endless. Colour control, transparency, texture mapping, lighting properties, material properties,
perspective/orthographic projections, co-ordinate (matrix) manipulation (rotation, scaling etc) and timing functions
Interaction features
Point and click GUI interface. The work area has standard drop
down menus.
Point and click interface. The render window has a standard drop down menu to which items can be added/removed. Decoration can also be enabled to provide thumbwheels, sliders and
push buttons accessible via keyboard and mouse. Widgets provide a GUI during
development
Figure 1.7.1 Table of comparison for Matlab, Iris Explorer and OpenGL applications.
In a comparison with Iris Explorer and Matlab, OpenGL stands out as offering the most in terms of
visualisation features and the best support for cross platform operations. Compared to Matlab alone, it
offers more interactive features and is on a par with Iris Explorer with this respect. When comparing
the advantages and disadvantages of the three software alternatives, OpenGL makes the most viable
argument as the platform on which to base the visualisation project, not only in terms of
compatibility, availability and features but also in the fact that prior knowledge and experience of
using it, already exists. On a C++ foundation, the OpenGL graphical API and GLUT libraries make a
sound proposal.
GLUT and MESA
GLUT (OpenGL Utility Toolkit) is a windows system independent library of graphic functions that
implements simple window management for use with OpenGL. As the GLUT controls the window
management, menu management, call-back registration, colour variation, object drawing, and
initialisation, it makes learning OpenGL considerably easier [Skillsoft, 2000]. The latest version,
allows the user to create a single application in OpenGL that will work on Windows, Mac and Linux
machines without any need to write operating system specific code. The latest version of GLUT,
developed by Mark J. Kilgard, is not in the public domain, but is freely distributable without licensing
fees.[SGI, 2006]. However, Kilgard does state that “GLUT is not a full-featured toolkit so large
applications requiring sophisticated user interfaces are better off using native window system
toolkits.” [SGI, 2006]. This is unlikely to cause a problem as it is intended that a 3rd party interface
library will be used to create an appropriate user interface.
Mesa provides an open-source implementation of the OpenGL specification [Paul, 2006]. It is similar
to GLUT in that it provides an API, sitting directly above the OpenGL syntax and offers portability
for OpenGL applications to run on systems that have no other OpenGL solution.
On the face of it, GLUT and MESA are both well written and popular OpenGL toolkits; however the
availability of GLUT is more widespread in university and at home, therefore making it the choice for
this project.
6
1.7.2 Spatial Data Structures.
The organisation of spatial data structures, is usually hierarchical and as such is nested and recursive
in nature. The advantage of using a hierarchal structure, is that generally, queries become much faster,
with an improvement from O(n) to O(log n) [Moller, 2002].
Quadtree
The quadtree is a hierarchical data model that recursively partitions a two dimensional space into four
quadrants. The root node of the tree represents the complete domain and each node of the tree
represents a uniform subdivision of that domain. The quadtree gets it name from the fact that it always
divides a parent node into 4 smaller but equal child nodes, that each represent a quarter of the space of
their parent node [Figure 1.7.2.1]. As division is applied, child nodes become parent nodes, receiving
4 more children and they in turn become parents until the desired depth/level of partition is obtained.
There are several different forms of quadtree in use in a variety of situations. The region quadtree is
typically used to recursively subdivide a collection of objects into quadrants, until each object is
located within its own cell (tree node). With enough levels of recursion, each object will find itself
within its own cell and will therefore not be sharing a tree node.
Figure 1.7.2.1. Quadtree Example with 5 levels of refinement. (Lawlor, 2001).
Quadtrees are regular in nature, meaning that they deal with partitioning data in a uniform manner.
While this can be more restrictive it can also be far more efficient due to the predictable way in which
they handle data. The quadtree data structure was originally proposed by Raphael Finkel and J.L.
Bentley [Finkel, 1974] and has become a very popular method for image representation, spatial
indexing, efficient collision detection in two dimensions, view frustum culling of terrain data and
storage of sparse data [Tremblay, 2004].
7
Octree
An octree is fundamentally the same as a quadtree but works in a three dimensional environment.
Each parent node has eight child nodes that represent a refinement in space of the x, y and z
dimensions. Each leaf node therefore becomes an octant of its parent node and presents a cuboid
shape in physical space [Philips, 2002]. In an ideal dataset of equally distributed objects, an octree
would provide a balanced data structure. In reality, a clustering of data will produce a very un-
balanced tree, as uniform partitions would require a large recursion to divide the dataset up. A k-d tree
attempts to solve this problem by dividing space un-evenly. [Tremblay, 2004].
Figure 1.7.2.2. Octree hierarchy. Adapted from [Lachance, 2005].
BSP Tree
A Binary Space Partitioning Tree Data Structure uses arbitrary splitting planes to recursively sub
divide regions of the domain. They exist in two noticeably different forms, axis-aligned and polygon-
aligned, the difference being that the former makes use of bounding boxes within the scene, to equally
divide (or not) space depending upon the algorithms involved, and the latter, choosing to use edges
from the shapes within the scene to generate splitting planes [Haines, 2002]. Both approaches are
undertaken in a recursive manner, gradually dividing up the scene into smaller and smaller
compartments until the desired level of detail is achieved.
To store the data on each side of the binary tree, the partitioning algorithm assigns the left-hand leaf
nodes as negative and the right-hand leaf node as positive. Once an object within the scene has been
chosen as the basis of the splitting plane, all objects to the positive side of the plane are placed in the
positive side of the tree (the right-hand side).
8
Figure 1.7.2.3. BSP splitting planes and associated tree structure [Philips, 2002].
All the items appearing on the negative side of the plane are placed in the negative side of the tree (the
left-hand side). The positive and negative sides of the plane are dictated by the positioning of a
control within the domain, with the positive side being closest to the control and the negative side,
further away [Figure 1.7.2.3]. In computer games the control would be the camera (player). Where a
non-uniform item is chosen as the splitting plane, the direction and location of the plane is determined
by finding the shortest vector from plane to item boundary [Figure 1.7.2.4]. The item can then either
be split in two, with one half belonging to the positive side of the tree and the other to the negative, or
for simplicity (at the expense of performance) ,the entire item can be placed in both the positive and
negative side of the tree.
Figure 1.7.2.4. Positioning the splitting boundary [Philips, 2002].
Binary Space Partitioning Trees can be employed in more than one dimension of space if required but
usually quadtrees and octrees are preferred for two dimensional and three dimensional subdivision
due to the complexity of keeping track of splitting planes and their vectors in 3D dimensions
[Tremblay, 2004].
9
k-d tree
A k-d tree is a form of BSP tree that uses splitting planes perpendicular to the x, y or z axis. The ‘k’ in
k-d tree refers to the number of dimensions that the data structure is deployed in. A 1d-tree would deal
with splitting the area along just one axis. A k-d tree provides a balanced option to using a quadtree or
octree, as it divides space unevenly in such a way that one half of the tree holds as many objects as the
other half [Tremblay, 2004].
Conclusion
The construction of most spatial data structures is expensive, and is usually done as a pre-process
although incremental updates are possible in real time [Haines, 2002]. This is not such a disadvantage
if loading times aren’t crucial, as once the tree has been set up, the performance gains can be very
impressive. The major use of spatial data structures is in the games industry, where their use in culling
and collision detection allows for higher FPS speeds and finer detailing [Tremblay, 2004].
From the 4 data structures discussed, the quadtree displays the best attributes for use in an Adaptive
mesh refinement simulation and in storing and processing the OTT-2D data. The reason for this
choice is that the quadtree firstly matches the 2D state of the OTT-2D and secondly, is very similar to
the way in which the model stores wave data for each mesh refinement. Constructed from recursively
quartering cells into equally sized squares, it is ideally suited to the Cartesian mesh structure of the
OTT-2D model where each mesh cell is presented as a quad.
1.7.3 Adaptive Mesh Refinement
Adaptive mesh refinement (AMR) is a computational technique for improving the processing and
storage efficiency of numerical simulations. Refinements in both space and time, to selected regions
of the computational domain allow for higher detailing of important and interesting features, while
less interesting parts are left at lower resolution. This approach offers more efficiency than drawing
the entire domain at high resolution as the processor is required to do less work. So, for a small
increase in processing power over the requirements for a coarse simulation, highly refined proportions
of the domain are possible.
10
Figure 1.7.2.5 AMR with 3 levels of refinement [Quirk, 1994]
Adaptive Mesh refinement was first discussed in a series of papers [Berger, 1984. Berger, 1989] in
which, an algorithm for local adaptive mesh refinement was developed to achieve dynamic gridding.
The algorithm starts with “a coarsely resolved base-level regular Cartesian grid” and “progressively
calculates individual grid cells that require refinement” [Berger, 1984]. The criteria for choosing
higher refinement, can either be user-supplied (refine cells where value x is greater than y) or based
on a numerical analysis method such as Richardson Extrapolation [Israel, 2002], that gives acceptable
approximations as to where high detail will occur. Cells which are marked for refinement are then
processed in more detail and the resulting higher resolution mesh is overlaid onto the base grid. A
correction procedure is implemented to check that no two meshes of similar refinement level overlap
or that no two different levels of refinement share boundaries if they differ by more than 1 level of
refinement. This process is repeated, so that the finer mesh from the previous progression now
becomes the base grid on which refinement requirements are calculated. Where more detail is
required, an extra refinement will overlay the previous resolution of mesh.
The Berger Oliver Method
The Berger Oliver Method of adaptive mesh refinement differs in comparison to usual unstructured
adaptive methods in the way it picks and handles cell refinement. Instead of replacing single cells
with finer ones, the algorithm proposed by Berger and Olive, utilises a patch-wise algorithm, whereby
cells flagged for refinement are clustered into rectangular sections ready for processing. [Berger,
1984]
11
Once the finer cell values have been calculated, interpolation functions are used to transfer the values
to the coarse grid. Cell values on the coarse grid are covered by the finer mesh and overwritten with
averaged fine grid values. The resulting extra work is “usually negligible compared to the
computational costs for integrating the superimposed refinement grids” [Berger, 1984]
One of the areas in which AMR is predominately utilised, is in astrophysical simulations and image
manipulation, an example of which can be seen in the collapsing giant molecular cloud core
simulations of Klein et al. AMR techniques allowed for a reduction in resolution of 131,072 cells
compared to 1015 cells in a uniform grid [Klein, 2004].
The advantages of AMR can be summarised as the following:
• Increased computational savings compared to the majority of static grid approaches.
• Increased storage savings over a static grid approach, therefore reducing processing
requirements.
• Control of grid refinement and resolution when compared to the fixed resolution of a static
grid approach.
AMR has the disadvantage of being significantly more complicated and therefore more time
consuming to develop in applications when compared to the algorithms and data structures used to
create standard uniform meshes. Intricate and complex data structures required to fulfil AMR, such as
Quadtrees and Octrees are not available as standard classes in all object orientated languages and as
such must be coded from scratch (the Java SDK does supply classes but they are not available in
C++).
1.7.4 Existing AMR Visualisation Techniques.
The following projects are examples of existing visualisations that make use of AMR techniques
DAGH (Distributed Adaptive Grid Hierarchy)
DAGH is a data-management infrastructure that provides a framework for solving systems of partial
differential equations with adaptive methods [Browne, 2006]. Currently in use at the Universities of
Texas and Rutgers (USA), it has been used to implement reservoir simulations, numerical relativity
and geophysical modelling. It is currently possible to interact with the DAGH toolkit using the
FORTRAN 77, FORTRAN 99 and C++ languages. The DAGH tutorial [Browne, 2006] currently has
listed the following features that are provided by the software.
• Distributed dynamic data-structures for Parallel Hierarchical AMR
12
• Transparent access to scalable distributed dynamic Arrays/Grids/Grid-Hierarchies
• Multigrid/Line-Multigrid support within AMR
• Shadow grid hierarchy for on-the-fly error estimation
• Automatic dynamic partitioning and Load distribution
• Scalability, Portability, Performance
It is clear that the system incorporates AMR techniques similar to those in the OTT-2D model and
with the aim of providing high resolution modelling to problems while keeping processing power to a
minimum. It is interesting to see that the model uses parallel processing for extra performance boosts
and shares some of the requirements expected of the OTT-2D visualisation such as portability and
scalability. While a nice feature, it is considered out of scope to add parallel processing functionality
to the OTT-2D visualisation due to the complexities involved and the developer’s lack of experience
in this area.
ENZO
Enzo provides cosmological simulation code that utilises a structured Adaptive Mesh Refinement
algorithm to solve a wide range of astrophysical and cosmological problems. It is freely available to
download from the Enzo Resource webpages [Bryan, 2006] and has various achievements including,
responsibility for the world's largest simulation of the early universe [Bryan, 2006] and several front
page articles in National Geographic and Physics World magazine. While Enzo provides purely the
AMR code, there are several visualisation modules available to use. One of the most popular is
Jacques [Figure 1.7.4.1] which provides several levels of control over the simulation data.
13
Figure 1.7.4.1. Enzo simulation running on Jacques visualisation interface [Abel, 2006]
Jacques [Abel, 2006] presents a clean and uncluttered user interface that is built upon the IDL toolkit
but is very similar to some of the OpenGL interface packages available to download [Section 1.7.5].
The Jacques interface helps to demonstrate the kind of manipulation tools that users of AMR
simulations are likely to require and makes a good basis on which to design the OTT-2D visualisation.
MATLAB
The author of the OTT-2D code [Hubbard, 2002] has currently implemented a single refinement mesh
visualisation within Matlab. At present the system only utilises one of the OTT-2D output files and
must be re-loaded each time to create a step through of the simulation. The visualisation displays only
the water surface behaviour and the coarsest level of refinement but is a good starting point on which
to base the new OTT-2D simulation.
14
1.7.5 Human-Computer Interactions within 2D/3D Environments
Throughout the project, the aim will be to create and provide visualisation techniques that deliver the
most appropriate and useful solutions to the end user. Feedback from the project supervisor and
author of the numerical wave model will help to guide the direction of design and implementation, in
areas such as efficiency and display requirements.
Initial thoughts during the early design phase, include a heads up display of animation controls,
allowing the visualisation speed and time parameters to be adjusted. With the provision of
pause/resume and rewind, the user will be able to revisit key scenes in the visualisation without
having to wait for completion of the sequence and performing a restart. The user should also have the
opportunity to explore the visualisation in a truly three dimensional aspect. To provide this, the heads
up display of controls could include options for zooming in/out/panning and clockwise/anti-clockwise
rotation. Finally the visualisation should provide some means of controlling lighting and colours, as
well as surface textures for the water, land and sea bed.
All aspects of lighting can be controlled within the visualisation using various OpenGL commands.
Basic flat surface colours can be manipulated to appear three dimensional through the use of ambient,
diffuse and specular highlighting. These properties typically control how light is reflected and
refracted onto and around a scene. Material shininess can be controlled and the type and position of
lighting can be altered. Multiply light sources are possible. Bilinear/trilinear and anisotropic filtering
can be used as required to smooth and accurately shade the 3D scene. Texture mapping is also a
possibility but will probably not be used due to performance implications and the likelihood of detail
masking.
Timing controls within the visualisation will be more difficult to implement. One approach could be
to count FPS (frames per second) and implement logic into the generation algorithm to control how
many iterations of the mesh are produced each second. Raising or lowering this value would speed
up/slow down the visualisation and could produce a pause effect. Using a FPS calculator will also be
a good solution to unify display generation (time to process and display each mesh implementation)
across different platforms and architectures.
GLUI
The GLUI toolkit offers an open source GUI library in the C++ language that can be used to quickly
build graphical user interfaces with interactive controls [Rademacher, 2006]. GLUI is built on top and
directly links to the GLUT libraries which mean it is platform independent and will operate on any
machine that supports GLUT. It relies on GLUT to handle all system-dependent issues, such as
window and mouse management so it is required that the GLUT libraries are present on the system to
15
in order to make use of GLUI. User interface features within the toolkit include the ability to add a
number of interface windows, the addition of interactive radio buttons, checkboxes, buttons and
spinners and ‘live variables’, where values linked to the interface controls are automatically updated
when the state of the control changes [Rademacher, 2006].
Figure 1.7.5.1. Example GLUI interface [Rademacher, 2006]
GLUI is known to be supported by the SOC windows machines and can be stalled on the Linux
computers without the need for administration privileges. A complete listing of features supported by
GLUI are available in [Appendix E].
1.8 OTT-2D Overview
The OTT-2D numerical model is part of a suite of numerical models ANEMONE, developed for HR
Wallingford, and funded by the UK Ministry of Agriculture, Fisheries and Food, and is intended for
use in the application of coastal engineering for predicting hazardous wave run-up and overtopping on
coastal structures. The model can “accurately model complex water motions in the nearshore region”,
something that existing linear models do poorly. OTT-2D can also overcome the simple wave and
beach profile selection limitations, of earlier empirical tools such as the flume and basin experiments
[De Waal, 1992] and the Manual on the Use of Rock on Coastal and Shoreline Engineering [MAN,
1991] by modelling complex wave behaviour without the need for flume tests. The 2D model (2D +1
in the fact that it models two directions of propagation, cross-shore and alongshore, and the element
of time) shares the fact that it is predominately based on nonlinear shallow water equations (NLSW)
with existing 1D models [Dodd, 1998] and [Titov, 1995]. However, it improves on 1D models by
offering simulations of “overtopping and regeneration by obliquely incident and multi-directional
waves over alongshore-inhomogeneous sea walls and complex, submerged or surface-piercing
features” [Hubbard, 2002]. To tackle the increased computational requirements of 2D over 1D
simulations, the model employs finite volume techniques and an adaptive Cartesian AMR algorithm.
16
Finite volume techniques allow the domain to be divided into a number of cells, where, in the case of
OTT-2D, the values of interest are typically located at the centre of the cell. Over time, AMR is then
employed to adaptively control the number of cells, using finer resolutions of grids where necessary
and as a result creating large computational savings. Within OTT-2D, increases in speed of 10 fold
are obtainable, [Hubbard, 2002] without any loss of accuracy when compared to a uniform mesh
displaying the same level of detail. The Adaptive Mesh Refinement algorithm used in OTT-2D was
developed by [Quirk, 1991] and works by refining with higher resolution, areas of the domain that
require more accuracy. It then calculates data values for the entire domain by using the values stored
in the finest mesh levels. The model has been extensively tested and in the majority of cases has
accurately reproduced numerical solutions. [Hubbard, 2002].
Feature List
The following list describes the inner workings of the OTT-2D numerical model and is taken directly
from the ANEMONE OTT-2D User Manual [Hubbard, 2000]:
• OTT-2D replicates processes usually studied in a laboratory using a scale physical model, but
is quicker to set up, requires fewer staff and costs less than a wave flume basin.
• A wide variety of wave conditions can be studied; either regular or random waves can be
specified together with associated ‘set-down’ or long waves created by groups of primary
waves.
• The model absorbs reflected waves at its seaward end, allowing long wave sequences to be
studied.
• The principle uses of the model are to predict the varying position of shoreline (i.e. wave set-
up) and overtopping rates.
• OTT-2D can also predict the water surface variations, wave induced velocities and
accelerations at any required location. These locations can be surf-zone, on a beach, on a
coastal structure or landward of it.
• The model will automatically store a wide variety of results, and can produce computer
animations of wave propagation for use in reports.
17
2 Design
2.1 Requirements
For the simulation to work effectively and accurately it will need to incorporate a number of
interdependent requirements.
2.1.1 Ability to Recognise and Handle OTT-2D Output Files
During a wave simulation run, OTT-2D will generate a number of files including data files of wave
calculations, as requested in the system parfiles. Each data file represents a slice in time during the
simulation, supplying the water depth, bed level and velocity in x and y directions for each point of
each mesh in the domain. The visualisation application will only be concerned with the data files
output from the OTT-2D simulator and will ignore any parfiles. The extension that is used by OTT-
2D to denote the files of output data have the extension .dat and in default take the form tpl000$.dat
where $ denotes a time slice in the simulation. The data output files are created in sequence so that
output file tpl0002.dat represents the timeframe of the simulation that occurs immediately before the
timeframe represented by tpl0003.dat and immediately after the timeframe represented by tpl0001.dat.
The visualisation application must be prepared to read in a small or large range of data files as
dictated by the input options of the OTT-2D code and be ready to accept the naming conventions used
in OTT-2D. This includes the naming of data files greater than 9 in sequence where a zero is dropped
before the number is appended (tpl0009.dat becomes tpl0010.dat and the filename remains only 7
characters in length) and similarly at sequence number 100 (tpl0099.dat becomes tpl0100.dat).
Within each data output file the underlying structure and layout of the data will remain the same. This
will include a header section of 5 lines holding the following information:
• Overall X and Y dimension values for the domain (base grid)
• Level of refinements used in that timeframe
• X and Y factoring in logical coordinates (quads of size X by Y)
• X and Y factoring in grid coordinates (quads of size X by Y)
• Total number of mesh in timeframe
These properties control the domain for the underlying mesh in one particular timeframe. Under the
header section, the data output file lists the data values corresponding to each vertex of each mesh.
Each mesh includes its own header section with the following information:
• Mesh Refinement Level (Is the mesh at the coarsest level or at a higher resolution)
• Mesh start position (Position X1 ,Y1 in logical coordinates)
18
• Mesh end position (Position X2 ,Y2 in logical coordinates)
• Mesh start position (Position X1 ,Y1 in grid coordinates)
• Mesh end position (Position X2 ,Y2 in grid coordinates )
• Mesh dimensions
For each vertex of mesh, there are 4 associated data values. These fall under the column headings:
• d (Total water depth)
• u (Instantaneous velocity in X direction)
• v (Instantaneous velocity in Y direction)
• h (Still water depth)
The output files provide a structured representation of the mesh simulation data, sequentially storing
the data for each mesh vertex in ascending order fashion whereby, coordinate (x,y) on the mesh
appears as the first entry in the output file and coordinate (x+1,y) appears second. It is also structured
in the sense that a complete set of data is offered for all mesh refinements, even where vertex points
are made redundant because they are overlaid in another finer resolution mesh. This structure is an
important feature that will allow refinement levels to be controlled via the application, allowing the
removal or addition of the refinement levels from display as required.
2.1.2 Facilitate Internal Storage of Simulation Data Values
The visualisation application must be able to open and load each output file from OTT-2D and
accurately store each value into system memory ready for use. The layout and structure of each data
file will remain the same, however each file will differ in a number of ways. Each file within one
simulation sequence will vary in size and as input parameters are changed, there will be a variation in
the number and size of files created in successive simulation runs. Due to the nature of AMR, the
location and amount of refinement are dictated through the implementation of the tagging algorithm.
This means that the number and size of mesh will change as the algorithms decide which areas of the
domain require higher and lower resolutions. If the problem domain requires a large amount of high
resolution mesh to display the wave simulation, then the number of vertex points will increase.
Similarly, if a high number of refinement levels are chosen, then the number of vertex points is also
likely to increase. Finally, the overall number of vertex points is dictated by the size and shape of the
domain.
The application must be prepared for these changes in dimension, refinement levels and resolution
requirements but also must be prepared to accept a change in the number of data files produced. These
19
variations are unpredictable and can only be determined once the OTT-2D algorithm has generated all
the data output files. The storage techniques employed by the visualisation must therefore be
completely dynamic:
• In the range of OTT-2D output data files (the operator of OTT-2D determines how many
steps each simulation will contain. If time remains constant, then longer simulations will
contain more steps and therefore more data output files).
• In the size of the domain (a 100x100 grid requires more data values than a 10x10 grid).
• In the level of refinement required. In a 10x10 domain with one level of refinement there will
be a maximum of one grid at the base resolution and one grid at twice the resolution (a 10x10
grid overlaid with a 20x20 grid in a worst case scenario). With 4 levels of refinement on the
same domain there will be 1 grid at base resolution, one at twice the resolution, one at 4 times
resolution and one at 8 times resolution (a 10x10 grid overlaid with a 20x20 grid, a 40x40
grid and an 80x80 grid in a worst case scenario).
• In the number of mesh required at each resolution (a complicated scenario may require a lot
of refinement in different locations within the domain, less complication requires less mesh
and therefore fewer data values).
2.1.3 Generate Accurate Representations of Wave Data in Mesh Form
The visualisation will use the data stored in the dynamic data structures to create a single mesh that
displays all the levels of refinement. The mesh will be built up as a series of quads that will
seamlessly link across areas of similar and different resolution without creating cracks or gaps in the
mesh. The mesh will appear to link between quad edges (except at boundaries of resolution change)
but will actually link between quad centres as the finite volume technique employed by the OTT-2D
model places all data values at the centre of the quads [Hubbard, 2002]. Using a quadtree structure,
the user will be able to add and remove levels of refinement from showing just one mesh (the base
and coarsest mesh) to the maximum number of mesh as defined in the OTT-2D output files, and still
visualise a solution without cracks and gaps. With a timing structure implemented, the user will be
able to run a step by step simulation of the wave run up with user defined levels of refinement.
As coordinates for the individual quad vertex points are not given in the structured data files, the mesh
will be rendered using the start and end points as defined in each mesh header block. The rendering
method will use a nested for-loop and a count variable to iterate through each row and column of quad
vertices, gradually building up the mesh. To calculate the level of the surface water, the renderer will
use the depth value - bed value. For displaying the velocity vectors the renderer will use the cross
product of the x and y vector components.
20
2.1.4 Control Simulation Timing
Timing is a key component to creating an effective visualisation. It is fundamental that the application
allows step by step generation of the simulation in a timed and regular fashion while still offering the
user control over speed and direction. The user should be able to replay the simulation step by step, as
many times as required without having to reload data from disk or output files and without having to
exit and re-run the application as this would create unacceptable periods of user inactivity. To create
the periodic steps between each stage of the simulation, the application must have access to some
form of accurate and regular time keeping device that is irrelevant of processor clock cycles or
performance capabilities (this is only necessary, provided that the processor in question falls into the
categories discussed in 2.2 Hardware requirements). Controlling the run of the simulation through the
use of clock cycles would make it impossible to predict the timing on different machines, with slower
processors running the simulation over larger time periods than faster processors. In a similar manner,
using a Frame per Second (FPS) calculator could control the simulation, but run times would vary
across different platforms with more recent and powerful graphics cards having the capacity to
generate and display each mesh cycle in less time than older hardware. The only viable solution to
creating a standardised run time across different platforms and hardware is to use calls to the
Operating System time keeping operations. All operating systems based on the X86 architecture
facilitate the means to query time measured in the SI unit of seconds. Many of the applications that
run on the OS require the OS time keeping operations but it is most obvious to the user in the form of
the clock, displayed in the bottom right-hand corner of the screen in the Windows and Linux
Operating Systems. The OS keeps an accurate and orderly track of universal time by querying the
battery powered CMOS chip on the computer motherboard during start up. The OS will then keep a
uniform track of universal time regardless of the processor speed or graphics card on which the OS is
displayed. While methods are available to access the OS time keeping operations, these methods will
appear and behave differently across different platforms. This means that to allow the visualisation to
run across the Windows and Linux environments, there will have to exist separate time methods for
each operating system and there will be the requirement for different libraries/header files to be
loaded. It will become clear during the implementation and evaluation stages, the amount of extra
work required to implement this across the two platforms and how similar the visualisation timing
performs under Windows and Linux.
2.1.5 Allow Simulation Manipulation
Using interaction techniques the end user should be able to manipulate features of the simulation such
as viewpoints; scaling, panning and rotating; control lighting intensity and position, control the speed
at which each timeframe is played and have the ability to choose any timeframe to revisit.
21
2.1.6 Support Cross Platform Operation
Through the use of OpenGL and C++, it should be possible to compile the project on any Windows or
Linux system that is setup with C++ and OpenGL compilers and necessary libraries. This includes the
vast majority of workstations within the SOC. Once compiled it should be possible to run the
visualisation application on any Windows or Linux machine without the need to install new files, add
libraries or alter existing system files. Using the windows based C++ compiler provided in Microsoft
Visual Studio will create an executable of the visualisation application that will run under the
Windows environment. Using the C++ compiler g++ on the SOC Linux machines will create an
executable that will run under the Linux environment.
2.2 Preliminary Design
To meet the minimum requirements of the project [Section 1.3] and achieve the requirements
discussed in the design requirements [Section 2.1], the application will have to make use of the
following the functionality:
2.2.1 Vectors as Dynamic Storage Elements
The C++ language includes a library which can be used for dynamic data storage. The vector.h library
allows the user to incorporate a container template within their application that behaves in a similar
manner to the array structure but is dynamic in the sense that the length of the structure does not have
to be declared before use. With an array, the maximum size of the contents must be declared using a
constant value, before the array can be used to store any data. This is a severe limitation, as the length
and number of wave data values will change unpredictably between different runs of the OTT-2D
simulation. If the application cannot adjust to take the extra values that may occur in the OTT-2D
output files, then the visualisation will not be displayed correctly and could be considered as invalid.
A vector does not require its length to be declared before use and instead incorporates memory
management techniques to expand the structure as new elements are added. Vectors will allow any
number of values to be added without the need for change in the structure that is apparent to the
programmer or user, and will accept all types of data including user defined data types like ‘struct’
and class. Appending items to the structure is done simply with the ‘push_back’ command and any
item within the vector can be accessed using the same methods that apply to the array structures
[Jenkins, 2003].
MeshVectors->push_back(any_item); Temp = MeshVectors [x];
22
Accessing members of a vector or appending elements can be done in constant time, whereas locating
a specific value or inserting elements into the vector takes linear time.[Jenkins, 2003] While it is easy
to create a 2D or even 3D array within C++, the vector container is only a 1D data structure. To create
a 2D vector, a vector structure that holds a list of vectors must be created (i.e. a vector of vectors).
typedef vector<float, allocator<float> > MESH; typedef vector<MESH, allocator<MESH> > MESH_LIST; typedef vector<MESH_LIST, allocator<MESH_LIST> > MESH_TOTAL;
As a number of 2D vectors and possibly 3D vectors will be required to correctly handle the OTT-2D
output files, several structures, as demonstrated above, will have to be created.
2.2.2 Using a Quadtree for Mesh Joining at Different Levels
Using the structured OTT-2D output files, the visualisation will need to implement a data structure
than can store and allow retrieval of each mesh refinement in such a way as to prevent overlap and
gaps/cracks where the refinements meet. The rules for refinement as used in the OTT-2D numerical
model state that, two mesh of similar refinement level can never overlap and no two different levels of
refinement can share boundaries if they differ by more than 1 level of refinement [Hubbard, 2002].
The proposed solution to the overlap and gap problem is the implementation of a quadtree structure as
discussed in [Section 1.5.2]. A quadtree will be created for each quad on the coarsest level of the mesh
(the base mesh) and in its root store the depth, bed and velocity components associated with that quad.
As levels of refinement are added to the mesh, it will become apparent which quads will be refined
and replaced. When this occurs, the values stored at the root of the quadtree will not be deleted but
instead 4 new nodes will be added to the tree, branching from the root node. The new leaf nodes will
hold the depth, bed and velocity components for the finer mesh quads that overlay the coarser quad.
This process will repeat until all refinement levels have been added to the quadtree structures. It will
then simply be the case of reading from the ends of each quadtree branch (the leaf nodes) to get the
finest values for each area of the mesh and the depth of the leaf node to determine the scale at which
the vertices should be plotted.[Figure 2.2.1].
23
Base Mesh
1st Level of Refinement
2nd level of refinement
Figure 2.2.1. Skipping leaf nodes to create refinement joins.
The quadtree approach has the advantage of allowing refinement levels to be removed and re-added at
will from within the visualisation. If the quadtree stores 4 levels of refinement but only 2 levels are
required then traversal of the tree can occur down each branch to a maximum depth of 2 [Figure
2.2.1]. The disadvantage to the quadtree approach is the extended processing power and storage
requirements of building and traversing a large number of trees. If a mesh of 40x40 is simulated, then
1600 quadtrees would be required and this would simulate only one timeframe of the simulation.
2.2.3 Lighting and Normals
Several different forms of lighting can be used within an OpenGL scene to add characteristics such as
highlighting and reflection, and with the aid of the stencil buffer, shadowing. Two forms of lighting
will be used within the application and could be controlled in terms of positioning and intensity via
the user interface. Ambient lighting will used to add backlighting to the entire scene so that no area of
the mesh falls into permanent shadow. Ambient illumination describes light that has been scattered
around the environment to such a large degree that it appears to travel from all directions and usually
occurs because the light has refracted from a large number of surfaces before reaching the eye. A
specular component will be added to scene lighting so that a stronger directional influence can be
used to pick out, from surrounding areas, particular areas of interest on the mesh surface. The specular
light is preferred to the use of diffuse lighting, as it doesn’t scatter on impact with the surface and if
not too intense, can give nice highlighting to the area of interest. The strength, colouring and position
of the lighting in the scene will be controlled using the standard OpenGL lighting functions [Wright,
2000]
GLfloat LightAmbient[] = {0.4, 0.4, 0.4, 1.0}; GLfloat LightSpecular[]= {0.0, 0.0, 0.0, 1.0}; GLfloat lightPos[] = {0,100,0,0};
24
Using averaged normals to control lighting within the scene, will give the impression of a smooth
rather than faceted surface to the water and bed topography mesh. To create a smooth impression the
normals are averaged between neighbouring quads so that hard edges are smoothed out. The normal
of each quad is the element perpendicular to the quad face [Figure 2.2.2] and are calculated by finding
the cross product of three vertices within the quad (so long as the three vertices do not lie in a straight
line) [Redbook, 1994].
Figure 2.2.2. Calculating a normal [Redbook, 1994].
It is not yet known how effective the implementation of normals or lighting will be in the scene,
especially as the mesh will ideally drawn using a wireframe superimposed onto the solid fill of the
quad. As normals serve to smooth a faceted surface, the appearance of the wireframe will just add
back a definition of the quad edges that the normals removed. Although it can be assumed that the
extra code and algorithms needed to detect the normal for each quad in the mesh will require more
processing power from the CPU and could therefore reduce rendering speed.
2.2.4 Creating Timeframes
The use of timing functions will differ across the Linux and Windows platforms. This is due to
different libraries and routines that are used to keep track of time in the operating systems.
Unfortunately, developing the timing functions will take twice the amount of effort and time to fulfil
the requirements of both systems. Where the windows system is concerned, the use of the windows.h
will provide access to the method timeGetTime(), which retrieves the current system time in
milliseconds. Using current time as the starting point, the application will need to create and keep
track of the time intervals between each timeframe either through the use of the accurate performance
counter, or if not available, the multimedia timer. The Linux variant will operate under similar
principles but will use time retrieval and time counting methods that are available to Linux C++
25
compilers. As windows.h is a windows only header file, the application will need to inform the
compiler to load it if it current resides on a windows machine, or ignore it if it is on a Linux machine.
2.2.5 Using the GLUI Toolkit for Creating Interactive Controls
Version 2 of the GLUI toolkit will be used to create the interactive user interface as it is the most
recently supported release and offers the most functionality to date. The toolkit has been designed
with platform independency in mind and as such will run across and appear identical on any operating
system that supports the OpenGL framework and GLUT libraries. The toolkit offers a number of user
controls that can be placed onto menu bars and can be coded to perform actions such as rotation,
linear transformation, checkboxes, radio buttons, text box input and command style buttons. The
implementation of the GLUI interface occurs in the main method of the application and uses separate
methods to perform actions when each interface tool is used.
Void main {
glui=GLUI_Master.create_glui_subwindow(main,GLUI_SUBWINDOW_RIGHT); glui->add_button( "Run", RUN, control ); …
} Void control{
if ( control == RUN ) { runscenerio(); } …
}
The above code, demonstrates how the GLUI windows are created and placed into the scene at the
desired locations (first line in main method) before each control is added. Each control is given a
style, as it appears on screen (second line main method), in this scenario the control is a command
style button as found in the majority of graphical user interfaces. When the control is activated via the
user interface it calls an appropriate action in the control method which in turn initiates the desired
transaction. The GLUI interface will be used in the visualisation to create a side panel of tools for
controlling the simulation run, rotation, panning and scaling functionality.
2.3 Hardware Requirements
Machine specifications will influence the visualisation loading times and overall usefulness of the
interaction techniques employed. For the user to experience and manipulate the visualisation in real-
time, a speed of 25FPS or higher must be achievable. With vertex arrays and Vertex Buffer Objects
employed where available, unnecessary load from the CPU should be switched to the GPU. With this
in mind, a reasonable 3D accelerator will be required and a CPU capable of performing
transformation and lighting matrix manipulation. The machines available in the laboratories of the
SOC will be more than adequate with specifications of around 2.8Ghz for the CPUs and Geforce
26
series 4 and 5 graphics cards. The absolute minimum specification for a mesh of maximum size 50x50
and maximum level of refinement 4 would be for a PentiumIII 1Ghz processor and a Geforce 4 series
graphic card [Section 5.4]. As mesh sizes and refinements increase so will the specifications required
to run the simulations.
2.4 Software Requirements
No additional files or setup will be required to run the executable of the simulation provided that the
system has present the library for GLUT. If this is not he case then the library can be made available
simply by placing the file GLUT32.DLL inside the windows\system folder. GLUT is available
to download from the Nate Robins OpenGL GLUT for Win32 website and is open source.
27
3 Implementation 3.1 Methodology
In terms of software development lifecycles, the project will only have a short time to produce the
final solution. For this reason it is important to use techniques that track and counteract time scale
slippage throughout the development phase. Communication and understanding between team
members will not factor as there will only be a single developer working on the system and therefore
a rapid prototyping approach can be used to get a working demo of the visualisation up and running in
a short time. When this is complete the project can move onto an iterative development process,
allowing the developer to test and re-design each step as is required. The iterative process will allow
the visualisation to be built in stages starting with the basic framework. When this has been tested and
proven to be stable, it will allow further functionality to be added which in turn can be tested and then
altered if required. When a new component operates correctly and meets its requirements,
development can shift to the next piece of functionality where the build, test and re-design cycle will
be repeated. Finally, a third phase will allow for the re-design of particular sections of the project
without placing the project time scales in jeopardy.
A suitable methodology to use in this scenario would be the Rapid Application Development process,
developed and published by James Martin while at IBM in the 1980s. The RAD process is a direct
response to the non-agile development processes offered by models such as the Waterfall lifecycle
and has the key goal of combating long project development lifecycles. RAD allows applications to
be developed quickly thus avoiding complications such as last minute requirement changes that can
render finished applications unusable and also improves quality, as on shorter projects costs are less.
However, the downside of the RAD, is that the fast prototyping approach can reduce scalability and
features.
3.2 Development Plan
A Gantt chart displaying the project deliverables is shown in Appendix B in both initial and final
forms. The Gantt chart is an invaluable asset in project planning as it provides a very clear visual of
the project steps, how they interrelate and how long they will take. Using the Gantt as a comparison
with the current progress of a project, will quickly show any slippage and how this will have an affect
on other elements of the project.
The following table demonstrates the key milestones and dates for successful completion of the
project, meeting all the minimum requirements and delivering the solution on time:
28
Date Deliverable Description
Requirements Gathering
End Nov‘05
Project aim and requirements discussed
Project aims, minimum requirements and possible future enhancements discussed.
Phase 1 End Dec‘05
Completion of input/processing algorithms, rough single layer
mesh, displayed on screen
Completion of algorithms for reading in external data files, storing and manipulating the data ready to
generate mesh simulations. Start of on-screen mesh visualisations.
Phase 2 Mid Feb‘06
Implementation of single layer mesh with some manipulation
techniques
On screen visualisation of 3D waves using a single layer mesh and with user manipulation features such
as zoom/pan Phase 3
Mid Mar‘06 Addition of multiple layer adaptive
mesh refinement Addition of algorithms to deal with the adaptive mesh
refinement Phase 4
End Mar‘06 Further work on manipulation
techniques Work on mesh layer colouring and bed topography
settings. Phase 5
Mid Apr‘06 Incorporation of possible
enhancements
Figure 2.2.1. Skipping leaf nodes to create refinement joins.
3.3 Development Phases
Phase 1
Following the methodologies of the RAD process, the user requirements collected were used to
quickly build a simple, working visualisation solution. This initial phase concentrated on developing
the methods required to read in 1 level of mesh data and display the mesh on the screen and
importantly provided the basic framework on which the rest of the application was based. The initial
file reading and mesh drawing methods were tested for stability using a selection of data files of
various sizes and values and then used to demonstrate the underpinnings of the visualisation. The end
user was able to appraise the basic functionality and provide critical feedback on expected behaviour.
When it was agreed that the application was correctly accepting the OTT-2D files and drawing the
anticipated mesh, development moved onto the next phase.
29
Figure 3.4.1. Initial plot of water surface.
Phase 2
At this stage it was decided to switch from applying manipulation techniques outlined in the
development plan, to concentrating on the development of a multi-layered mesh. Due to longer than
planned development in phase 1, manipulation functionality was pushed back to phase 3 and attention
in phase 2, switched to applying the adaptive mesh refinement with the quadtree implementation.
Adhering to the time boxing element of the RAD development methodology, it was decided that the
building of manipulation techniques should be switched to phase 3 allowing development to focus on
incorporating minimum requirements. While the interactive element was still seen as important, it was
assumed that these techniques would be far easier and quicker to implement that the adaptive griding
functionality. Unfortunately, it soon became apparent that the design and implementation of the
quadtree structure would not be possible under the project time constraints. Attention switched to
alternative solutions [as described in 3.5.3 and 3.54] and an adaptive mesh visualisation without
overlap was achieved using unstructured mesh data. The adaptive mesh was tested for stability using
different input files and improved to show bed topography and surface water simultaneously.
30
Figure 3.4.2. Plot of water surface and bed topography using unstructured data
Phase 3
Phase 3 concerned the implementation of basic manipulation techniques. Keyboard control for
panning and zoom was implemented alongside functionality allowing mouse movement to control
rotation about the x and y axis within the scene. A numbering system based on the keyboard number
keys was developed to control the stages of the wave run-up simulation. At this stage, minimum
requirements had been met, if not in the way originally intended. After a series of tests to confirm the
rotation and linear transformations were operating correctly, development switched to phase 4.
Phase 4
A fully interact user interface was incorporated using the GLUI toolkit [1.7.5 GLUI ]. Development of
the features available in the toolkit provides a fully windowed, system independent means for the user
to control the visualisation. The addition of rotation and translation controls were used to give
complete 16 point rotation, scaling and positioning of the scene and lighting. Keyboard control of the
simulation timeframe was removed and replaced with a slider allowing any step of wave flow to be
revisited regardless of the number of steps within the simulation (the keyboard is limited to a
maximum of 10 steps as there are only 10 number keys). Fine tuning and re-testing of the control
sensitivity was carried out to make sure that scene rotation and simulation timings were of practical
speed.
31
Figure 3.4.3. Plot of water surface and bed topography using unstructured data and user interface.
Phase 5
From initial testing it was clear that the visualisation speed was too slow to allow seamless human
computer interaction. The inefficient calls to the OpenGL drawing primitives [Section 3.5.1] were
replaced with vertex array [Section 3.5.1] functionality, which had the added bonus of reducing the
data file loading times [Section 5.4]. As a result of implementing vertex arrays, vertex buffer objects
[Section 3.5.2] were incorporated to deliver huge reductions in rendering times and allowing extra
features such as transparency and anti-aliasing to become viable. To aid in cross platform operability,
it was decided that a move to the GLUT timing properties would be beneficial. This replaced the
current timing methods that had to exist in two instances, one for the Windows environment and one
for Linux and as a result was far easier to implement. Checkboxes were added to the GLUI user
interface to allow the user to control display options including viewing the animation in wireframe
mode or solid fill, showing vectors of the wave velocity for each time frame, displaying the wave and
bed topology independently or simultaneously and displaying and adjusting the level of water
transparency. Also incorporated into the user interface were buttons to start an unaided simulation run
and reset buttons to place the camera into predetermined viewpoints. To adjust the speed of the
32
simulation, a slider was incorporated to control the time intervals between the display of each
timeframe. To round off the user interface, a FPS calculator was created and used to display the speed
of running visualisation over each second.
Figure 3.4.4. Plot of transparent water surface, bed topography and user interface.
3.4 Description of methods
FileParse
The FileParse class is responsible for opening the OTT-2D output files, reading in the data values and
storing them internally within the application so that they can be accessed by the DrawMesh method.
Using C++ input streams (fstream), the application is able to locate and then open the relevant OTT-
2D files. If the correct output files cannot be located or for some cannot be opened, the FileParse
method has error handling techniques to alert the user.
33
file1 = ("unstr"+ostr.str()+".lat");
ifstream lat(file1.c_str()); if (lat.is_open()){ .. }
if (!lat){ cerr << "Error: File " << file1.c_str() << " cannot be opened" << endl; }
The FileParse method handles the reading of data values from both the unstr.lat and unstr.pyr files,
first reading in all the entries from unstr.lat file and storing the x and y coordinates, depth value, bed
value and, x and y components of velocity into a 1D vector. Using the values in the unstr.pyr file, the
DrawMesh method can now cross reference with the values in the vector abstracted from the unstr.lat
file to fill another 1D vector with a sequential list of all the mesh coordinates, depth and vector
components needed to recreate the mesh from the OTT-2D algorithm. To add the time component of
the visualisation, the Fileparse method simply loops through the required number of frames (specified
by the user on the command line), reading in and cross referencing the values from the relevant
unstr.lat and unstr.pyr files so that a 2D vector containing a sequential list of each 1D mesh is created
[Figure 3.4.2].
DrawMesh
The drawMesh method is responsible for recreating a graphical mesh representation of the data values
collected from the FileParse method. To achieve satisfactory display times using OpenGL, the
DrawMesh function utilises vertex array and vertex buffer objects [Sections 3.51 and 3.52
respectively] but is also responsible for applying viewpoint and model transformations, mesh
colouring and scene lighting. Calls to the OpenGL colour command, (4fcolour) are used to give the
surface water areas of the mesh transparency while ambient, diffuse and specular lighting components
are used to control the appearance of light and materials within the scene. The DrawMesh method
applies the viewpoint and model transformations by calling the Camera function which in turn
receives the model transformation matrix values from the move and MouseMove methods. The
drawMesh method is repeatedly called from the Main method to create a dynamic rather than static
visualisation.
Init
On loading the visualisation, the initialisation method is called and occurs immediately after the
GLUT display and windows are created by the main method. The Init function is only ever called
once as it is responsible for the setting up the perspective in the scene.
34
Main
The main method is responsible for controlling the order of all the other method calls. It is also where
the GLUT window creation occurs and where the GLUI interaction tools are built. The
glutMainLoop() command is used to initiate the continuous cycling of the DrawMesh function.
RunScenerio
The RunScenerio method is used to increment through each mesh of the simulation when the user
selects the ‘Run’ option on the GUI. It takes a time variable chosen by the user and,
Using the GLUT command GLUT_ELAPSED_TIME , it achieves a constant moving simulation of the
change between corresponding meshes.
float fps; char sfps[10]; frame++; timesp=glutGet(GLUT_ELAPSED_TIME); if (timesp - timebase > 1000) { fps = frame*1000.0/(timesp-timebase); sprintf(sfps,"%5.2f",fps); glui_fps->set_text(sfps); timebase = timesp; frame = 0; }
FPS
The FPS (Frames per Second) method is responsible for calculating the speed of the simulation. Using
the GLUT command GLUT_ELAPSED_TIME, the FPS method creates a variable that calculates the time
elapsed, in milliseconds since the Init method was called. [The GLUT_ELAPSED_TIME command is
explained in more detail in 3.5.5].
Camera
The camera method is supplied with the transformation and rotation values calculated by the Move
and MouseMove methods. The method then uses these to apply the transformations and rotations
using the OpenGL commands glRotatef and glTranslated.
MouseMovement
The MouseMovement method, called in the Main method of the application, uses the movement of
the mouse to control the rotation of the scene about the x and y axis. The current position of the
mouse is constantly tracked and compared with the last known mouse position. If the current mouse
location value is greater than the previous position value, then rotation is applied in a clockwise
direction and if the current mouse location is less than the previous position value, then rotation is
applied in the anti-clockwise direction. The angle of rotation is then supplied to the camera function
either as a positive value, for clockwise rotation, or as a negative value, for anti-clockwise rotation.
35
Using the GLUT command glutMotionFunc() the rotation of the scene is only activated when a mouse
button is held in the down position.
Move
The Move method is responsible for controlling the linear transformations within the visualisation,
mainly the zoom (scaling) factor and panning properties. It tracks and adjusts the current panning and
scaling properties as dictated by the Keyboard method, incrementing and decrementing the scaling
and panning properties as required.
Keyboard
In the keyboard method, commands within the visualisation are assigned to individual keyboard keys.
The user is able to use these keys to control visualisation zoom, panning and rotation as well as
initiating a simulation run. When one of the control keys responsible for scene panning or scaling is
activated, it calls the Move method and passes a value that is used to determine whether the scene is
to be positively or negatively scaled or the direction the scene should be panned. In the case of
initiating the simulation run, the control key accesses the RunScenerio method.
3.5 Solutions to Problems Encountered
3.5.1 Vertex Arrays
For drawing large quantities of primitives such as triangles and quads, OpenGL offers a faster and
more efficient method. “The best way to provide a modern graphics accelerator with model data is by
using what OpenGL calls vertex arrays”. Vertex arrays replace the need to repeatedly call and supply
the vertex function with values to create the vertex of each shape
renderDevice->beginPrimitive(RenderDevice::TRIANGLES); renderDevice->sendVertex(Vector3(0,0,0)); renderDevice->sendVertex(Vector3(1,0,0)); renderDevice->sendVertex(Vector3(1,1,0)); ... (other vertices) renderDevice->endPrimitive();
Sending a vertex to the GPU on every frame will create a bottleneck as the GPU waits for the data to
arrive across the system bus from the CPU. It also demonstrates how inefficient repeatedly calling and
supplying values to a vertex function is, as in large models, the same values will be sent on multiple
occasions where the shapes that make up a mesh share their vertices. Vertex Arrays over come these
shortfalls by placing all model data into a contiguous chunk of memory. Akienne-Moller et al [Moller,
2002] point out that “Copying memory is expensive in and of itself, and it also pollutes the CPU
memory cache” so allowing the GPU to use pointers to navigate the array of model data, picking out
36
the relevant vertex data values in the correct order will limit the requirement for vertex data to
swapped in and out of memory. As the GPU uses less OpenGL calls and reduces the amount of data
that needs to be copied between the application and OpenGL, the user can expect to see a
considerable performance gain. As well as storing vertex coordinates, vertex arrays offer the
advantage of being able to store vertex colours, textures and normals. Vertex arrays were
implemented in the final phase of development in an attempt to increase rendering performance.
3.5.2 Vertex Buffer Objects
Vertex Buffer Objects, are a recent extension to the OpenGL language that offer increased rendering
speeds for large quantities of triangles, quads and lines, including triangle strips, quad strips and line
strips. Vertex Buffer functionality is obtained through the use of the ARB_vertex_buffer_object
which was approved by the Architecture Review Board (ARB) on 12th February 2003. As Vertex
Buffer Objects are a fairly recent addition to the OpenGL language, not all graphics accelerators will
support them, however this is a minority case as updating to a current graphics accelerator driver will
usually add missing functionality. Vertex Buffer Object functionality is available on all cards of
specification NVIDIA Geforce2 series or later and it is not expected that the 3D visualisation should
run at adequate speed on any lower specification than this.
Vertex Buffer Objects are an extension of Vertex Arrays, improving throughput by placing the Vertex
Array data into the graphics accelerator memory. As the idea behind Vertex Arrays is to store model
data in a contiguous chunk of system memory, it is relatively simple to swap the data chunk to the
graphics accelerator memory. Storing model data on the accelerator’s memory can vastly reduce
rendering in a number of ways. Graphics accelerator memory is usually much faster than system
memory with tighter timings and higher clock speeds (The very latest top of the range accelerators
sport DDRIII memory with clock speeds in excess of 1200Mhz and in quantities up to 512MB
compared to standard system memory of between 266Mhz and 400Mhz for DDR). It is the
responsibility of the onboard graphics accelerator memory to only store model data compared to
system RAM which is responsible for all the operating system tasks. This leads to system RAM often
being fragmented and polluted, making it difficult to store large chunks of graphics data without
splitting. Calling data from the graphics accelerator memory to the GPU for rendering is significantly
faster than requesting it over the AGP and system bus. Swapping the chunk of model data from
system memory to graphics accelerator memory in one operation before rendering proceeds, reduces
the overhead required to request each piece of model data across the system bus and is no longer
limited by the slow transfer bottleneck of the AGP.
Vertex buffer objects were implemented in the final phase of development in an attempt to increase
rendering performance.
37
3.5.3 Unstructured vs. Structured Output Files
Using an existing conversion script, unstructured data files can be created as an alternative method to
the structured OTT-2d output files. These scripts, written in Fortran 90, were created by the author of
the OTT-2d as a means of converting the structured output data files of OTT-2d into a series of
unstructured data files for the purpose of displaying the simulation in the Matlab software utility. The
advantage of the unstructured data files, is that they present a single uniform and contiguous mesh that
incorporates all the levels of refinements without repetition of vertex coordinates. This makes it
efficient for visualisation purposes and removes the need for a complex tree structure that could prove
extremely difficult and time consuming to implement therefore significantly increasing the chance of
project failure. What the unstructured files do not hold, and the structured do, is the redundant data
held under the finer levels of resolution. The structured files hold the data values for all mesh levels,
whether overlap occurs or not, which would allow functionality to strip away the finer meshes right
down to the coarse mesh in the visualisation, if so desired.
3.5.4 Handling the Unstructured Data Format.
The unstructured data files, as described in 3.5.3, provide an alternative to the structured but difficult
to process, output files produced by the OTT-2D numerical model. If the unstructured files do not
exist, then they must be created using the OTT-2D conversion script and the original structured output
files. The script takes one structured output file as an argument and produces two unstructured files
that can be cross referenced to provide 1 complete mesh that incorporates all the mesh vertex
coordinates over all the levels of refinement. The structure of the two files are different with one
providing a comprehensive list of all quads used to construct the mesh and the other file providing the
coordinates of each vertex of each quad as well as the water height, bed depth and velocity
components for that quad.
For example, the first quad of the mesh will be constructed from 4 vertices which will appear as the
first 4 values in the .pyr file however the first 4 values of this file are not the coordinates of the
vertices in question, they are pointers to the lines within the .lat file that contain the vertices
coordinates. The process must be repeated for every timeframe of the simulation, ending up with 2
unstructured files for every structured file.
The application must first open the .pyr file and store the first 4 values. It must then continue to
collect and store the next 4 successive values of the .pyr file, recognising them to be pointers to
coordinates within the .lat file that construct each quad, until the end of the file is found. When
reading is complete, the .pyr file must be closed and the associated .lat file opened. Using the stored
pointers, the application can read out all the values and coordinates that make up each quad and store
them ready to be rendered. The whole process is repeated for each timeframe in the simulation.
38
3.5.5 Using GLUT for Timing
Implementing a timing function within C++ has proved inefficient and problematic. To use time
functions under Windows the header file ‘windows.h’ must be available but must be added to the code
in such a way that it is ignored when compiled on the Linux operating system because the library is
not available under Linux. Providing the necessary separate functions to control time under windows
and Linux does work but increases code size and coding times dramatically. A simple and relatively
easy to build solution is available in the GLUT command: getGlut(GLUT_ELAPSED_TIME)
within the OpenGL libraries. As it is part of the OpenGL framework [SGI, 2006] it is platform
independent and will not require two implementations to compile under Windows and Linux. Calling
GLUT_ELAPSED_TIME within the application will create a variable that stores the time elapsed, in
milliseconds since the Init method was called. If a comparison is made between calling the method
prior and post one loop of the rendering method, then the time taken to render one frame (FPS) can be
determined.
39
4 Evaluation 4.1 Introduction
Throughout the design process an iterative evaluation process was present, using both Heuristic
[Nielson, 1994] and formative [Dix et al, 1998] methods [details are presented in Appendix C].
To gather a better understanding of the system and obtain a representative evaluation from various
perspectives, the final application will be appraised using the following approaches. The system will
first be evaluated against the minimum requirements stated at the start of the project to determine
whether the solution adequately fulfils its objective. A Heuristic evaluation as defined by Nielson in
Usability Engineering [Nielson, 1994], will be conducted to test the final usability of the visualisation
and the appropriateness of the user interface and will be followed with a final formative evaluation
[Bowman et al, 2004]. There will also be a short end-user evaluation and a comparison between the
initial solution and the final solution, in terms of functionality and efficiency. As each method of
evaluation provides a different approach to testing system qualities, there should be a better chance of
uncovering all the strong and weak system elements and reducing the risk that serious problems might
fail to surface.
4.2 Evaluation Against Minimum Requirements
The minimum requirements were developed through an understanding of the user’s visualisation
requirements. In meeting the minimum requirements set forth in section 1.4 of this report, the
visualisation application will provide a more efficient and meaningful depiction of the OTT-2D
numerical wave model output. As well as improving upon the current output of large binary files it
will also provide a better solution to existing models the user has built in the Matlab software. An
evaluation of the minimum requirements and any extra features that have been incorporated, follows:
Produce a Method of Processing and Storing Wave Run-up Data from External Data Files
The system meets and exceeds the minimum requirements for reading and storing the wave model
data. In the final solution the application is able to find the relevant data files (as long as they are
stored in the same directory as the application) and load them sequentially so that the timeframes of
the simulation are not out of sequence. The solution also, almost entirely makes use of dynamic data
structures which allow it handle any size of data file whether the size is in terms of overall mesh
dimensions or in terms of the number, shape, position and levels of refinement. Through the use of
custom built vector functions, the application is able to build a 2-Dimensional dynamic structure that
allows any range of simulation in terms of timeframes and data files (each time frame requires one
data file) as requested by the user at the command line. The application incorporates error handling at
the command line to prevent the user from entering incorrect simulation ranges (the user cannot load
21 files if only 20 exist) which would unexpectedly terminate the program.
40
Produce an Algorithm to Generate Efficient Step by Step Animations of the Wave Run Up
The application uses the data stored in the 2D vector structure to create a sequential animation of the
wave run up. The animation method meets the minimum requirements by allowing the use to initiate
the visualisation of the correct sequence of wave run up, from start to finish. It surpasses the minimum
requirements by adding extra control of the simulation timing. Using the slider control presented on
the user interface, the operator can select and view any timeframe of the visualisation either pre or
post simulation run. Using a second slider, the user can adjust the speed of the simulation, choosing
the length of time each timeframe is presented on screen from a minimum of 1second to a maximum
of 10seconds. The time element of the simulation is controlled using the GLUT command:
glutGet(GLUT_ELAPSED_TIME), which has the added advantage of being platform independent
and independent of system specification. For example, when set at a constant value, the simulation
will run at the same speed across any hardware, irrelevant of the processing power of the graphics
card or CPU.
Employ AMR Within the 3D Visualisation of the Wave and Bed Topography
While the visualisation is not responsible for creating Adaptive mesh refinement or understanding
why certain parts of the mesh should be refined, it is expected that the system will accept and
correctly display data, held in an AMR format. The visualisation does achieve an AMR representation
of the sea topography and surface water, however not as first intended. Instead of using a quadtree
implementation, the application simply reads and stores an unstructured mesh of each timeframe into
a 2D dynamic structure and using grid coordinates, plots them to screen. Importantly, this method
displays a contiguous mesh of all refinement levels without creating overlap or gaps between the
different resolutions and correctly joins the cell centres where the depth and velocity components are
actually stored. It does however rely on the data being presented in unstructured format using existing
scripts developed by the OTT-2D author. Where the data is unstructured there is no clear
identification of when mesh resolution changes except to analysis the data for the proximity of the
coordinates of each mesh point and also means that where a finer resolution mesh is incorporated all
underlying data is lost. With a quadtree implementation, the user would be able to skip between the
mesh refinement levels, choosing to display mesh from the single coarse mesh, up to the maximum
mesh refinement but this is not possible using the unstructured data as the coarser level values are
replaced with finer ones before being loaded into the application data structures.
Employ Techniques to Manipulate the Wave Visualisation such as zoom/pan/rotate/colouring
The visualisation meets the minimum requirements for manipulating the scene by offering controls for
changing level of zoom, panning and rotation. The scene is also coloured although this functionality is
static and cannot be altered by the user, however there is functionality to create transparent surface
water and a means to control the level of transparency via the user interface. Further functionality,
41
above and beyond the minimum requirements is offered to the user in the shape of scene lighting and
inclusion of velocity vectors, both of which can be disabled or enabled via the control panel.
Checkboxes for hiding the surface water or bed topography are provided as well as the ability to
change between a wireframe view and a solid fill for the entire scene.
4.3 Heuristic Evaluation
Heuristic evaluation is a method of evaluating 2D User Interfaces using a set of ten heuristics laid out
by [Nielsen, 1994]. In simple terms, it is a method of looking and passing judgement on the usability
as one perceives it and taking note of any problems that inhibit that usability. Heuristic evaluation is
unusually carried out by a group of evaluators of between 5 and 15 people as studies have shown that
groups of 5 or more generally find 75% or more of usability defects [Nielsen, 1990].
Heuristic evaluations offer several advantages. They are usually cheap, require only small amounts of
planning, can be used throughout the design process and are generally intuitive in the sense that they
are based on an existing list of tried and tested rules (heuristics). The disadvantage of using such a
system, is that the focus of the evaluation is usually on the problems and not how to solve them
[Nielsen, 1990].
The following heuristic evaluation was carried out with a small test group of candidates and is based
on the 10 evaluation heuristics as proposed by Jakob Nielsen [Nielson, 1994]. The range of candidates
included, relatively inexperienced computer users with no experience of 3D modelling, relatively
experienced computer users who had reasonable knowledge of 3D graphics and OpenGL and an end
user with understanding of the simulation and OTT-2D underpinnings. Several heuristic evaluations
were used as part of the iterative design process. The statements given in this section are a final
heuristic evaluation of the system as it presently stands:
Simple and Natural Dialogue that the User can Understand
The system only enters dialogue with the user during initial loading. The dialogue occurs on the
command line in a textual format and serves to gather the relevant information on input files and to
provide information to the user while the input files are loaded. In the first instance of dialogue the
system asks the user to enter the number of files required to run the simulation. It is anticipated that
the user will know how many files they want to load and why the question is being asked of them
however, during the group testing phase, it became clear that not all users were expecting, or
understood why they had to choose the number of files to be loaded. The dialogue that follows the
input request, repeats the value entered by the user so that they are made of aware of an incorrect
entry and then continues to list the files as they are loaded into the application memory space. The
42
user will receive dialogue in the form of a command line error message if a certain file requested to be
loaded, cannot be found. This would be the case if the user specified a number of files larger than the
number of files actually available.
During testing it was agreed that the use of plain and simple language is consistent throughout the
application and in no way requires in-depth knowledge of computing related terms. Although users of
the system could not always answer the dialogue on system load they did understand what was being
asked of them. Within the user interface, labelling of controls uses simple English that can be
understood without knowledge of the underlying OpenGL techniques at work.
Recognition Rather than Recall (Minimizing the User’s Memory Load)
The only piece of information required to be remembered by the user, is the number of files to be
loaded into the simulation. The user must first know the amount of files required for the simulation
but can improve efficiency once the visualisation has loaded if they remember the number of files
used. The slider control for selecting the timeframe of simulation to be displayed to the user,
automatically calculates the first and last frame based on the number of files loaded. Therefore the
user cannot select an invalid timeframe. However, using the slider to go from the first to the last frame
of a large simulation is very time consuming (for instance 100 frames requires 100 clicks) so the user
can enter a timeframe to visit if they remember the number of files loaded. At present, there are no
instructions or user manual that can be accessed through the visualisation. Some of the test candidates
noted that this would be useful functionality and as such it has been noted for future improvement.
Consistency and Standards
For the user interface the visualisation uses the basic visual appearance of the GLUI toolkit. The
controls on the interface are very similar to those that are found in the win32 environment and most
other windowed based operating systems. All the test candidates showed an immediate understanding
of how to interactive with the controls and how to operate the mouse correctly to control the rotation.
Visibility of System Status
On launch, the user is made aware of the fact that the application is reading in the files to be used by
the simulation. As each file is opened for loading, the filename is immediately printed to the console.
Once inside the visualisation, the user is made aware of the current timeframe, if and only if they have
chosen to manually select it using the slider control on the user interface. If the user has entered the
timeframe via the slide control text input box then the timeframe number is displayed in the text input
box. If the user selects the timeframe using the slider control increment/decrement buttons then the
current timeframe number will be shown to increment/decrement accordingly within the text input
area. However, the timeframe value within the slider control text input box is not incremented if the
43
‘Run’ simulation button is used, instead remaining on 0 as the simulation runs through each
timeframe.
User Control and Freedom
The system comprises of a single window, in which the visualisation scene and user interface toolbar
is offered. There are no options to load up dialogue windows or message windows so the layout and
appearance is very simple to comprehend. With just a single window pane, the user should never find
that they have entered a chain of command that they cannot terminate. The use of checkboxes within
the application are an excellent example of the control the user has to undo and redo some of the
functions as all the user must do to reach the previous state is to perform the opposite of the last
command (i.e. uncheck the box if it is checked). The placement of several reset buttons allows the
rotation of the simulation to be changed to a predefined position, however the user does not have the
opportunity to stop the simulation while it is in progress. To exit the application the user only needs
to press the command button labelled ‘Quit’. During the final stage of testing it became apparent that
on lower screen resolutions, the ‘Quit’ command button would actually be pushed off the bottom of
the screen. At present the solution is to minimise the other toolbars so that they take up less space and
do not push the ‘Quit’ button off the screen.
Flexibility and Efficiency of Use (Shortcuts)
With an uncomplicated system there are very few occasions that warrant the inclusion of shortcuts,
the only instances being the input text boxes attached to the scrollers on the user interface. With these
input boxes, the user is able to specify an exact simulation timeframe, scale or lighting position
without having to scroll through a large selection of values. All the testers showed understanding of
the connection between the scrollers and the text boxes with some preferring to stick with the mouse
for interaction and others preferring to use the keyboard to input precise values.
Error Prevention and Error Messages
As stated in Heuristic evaluation [Nielsen, 1994], ‘even better than good error messages is a careful
design which prevents a problem from occurring in the first place’. The system almost reaches this
idealism as at present there is only one requirement for error checking and therefore one error
message. The error message ‘Cannot load file: filename’ occurs if the user enters more files to be
loaded than actually exist on the system. The error message is passive and requires no interaction
from the user, displaying the filenames to the files that cannot be loaded and instead choosing to just
ignore the fact that they were requested. Some users described this as confusing, noting down the
reason that, they are familiar with having confirmation options when presented with error messages.
Several solutions to this user input error are discussed in section [5.3]. The fact that the system only
required one instance of user input validity, is testament to the work involved in creating a closed and
44
error free system. With a simple and intuitive user interface it is impossible for users to enter invalid
commands.
Help and Documentation
At present there are no help files, either attached to the visualisation or in paper form, and only a
short, concise user manual that describes how to run and control the application, and how to use the
conversion scripts to convert from structured to unstructured files. It was noted by several testers that
a help section, attached to the application, would benefit users.
Aesthetic and Minimalist Design (Visual Continuity)
The user interface is built around the 2nd release of the GLUI toolkit. As such, the appearance of the
rotation and linear transformation controls cannot be changed. Aesthetically they are simple yet
convey their purpose very well with none of the test candidates noting down any problems with the
appearance of the toolbar. The visualisation is loaded up as full screen so there are no distractions
from the Operating system in terms of external windows, menus or taskbars. There are elements of
minimalism present in the toolbar, as each set of controls is grouped together under heading sections
that can be minimised to hide the controls grouped under it.
Late on the development cycle it was discovered that the reset buttons on the user interface did not
offer good visual continuity as, although they reset the position of the visualisation back to plan and
cross section view, when the mouse is used to change the rotation, the visualisation immediately flicks
back to its previous position before the reset was performed. At first users noted this as over-
sensitivity but on success test and closer inspection it became clear that it was a problem with the
code responsible for the rotation matrices.
4.4 Formative Evaluation
Formative evaluation is described as, “...an observational empirical evaluation method applied during
the evolving stages of design” [Bowman et al, 2004]. In simple terms, “…the method of judging the
worth of a program while the program activities are forming or happening” [Bhola, 1990].
Throughout the iterative design steps of the project, a formative evaluation was conducted to check
that newly added feature worked as expected. The majority of the formative evaluation was
undertaken by the developer using the test plan in [Appendix C].
4.5 End User Evaluation
A short end user evaluation was conducted, near the end of product development to try and highlight
any major deficiencies and possible future expansion possibilities for the system. The idea behind end
user evaluating, is to allow the client to get a feel for the product without any intervention from the
45
developer. This should help to get a clear and substantiated opinion of the application behaviour as
appears to the customer and not the developer. The end user was given free reign of the software,
asked to answer a series of questions and encouraged to give their opinion of the system. The outcome
is presented in the following figure:
Questions Answer Outcome
Mouse rotation from previous build was re-
instated to allow rotation via the mouse and the
toolbar controls. Reset buttons added to allow the
position of the visualisation to be instantly placed
into plan and cross section view.
Are you able to control
the position of the
visualisation as you
would like?
Yes, provided mouse functionality for
rotation is switched on and position reset
buttons are added to the toolbar
Are the loading times
satisfactory?
For large datasets the loading times are
too long.
A large improvement to undertake, therefore added
to future enhancements. However, still meets
minimum requirements
Is speed of visualisation
adequate? Yes None required
What aspects do you find
useful?
Ability to experience the scene in 3
dimensions and to rotate, pan and scale
around it.
Ability to simulate the wave run up and
to step forwards and backwards through
it using the step control
None required
What aspects are not so
useful?
Lighting does not cast any shadows
within the scene. Velocity vectors require
arrow heads to demonstrate direction
Large improvements to undertake, therefore added
to future enhancements. However, still meets
minimum requirements
What improvements
would you suggest?
Ability to move between mesh
refinement levels
Not possible using the unstructured files as the
data for the underlying layers are not present
Others
Time increments used to control
simulation speed are not in standard
format.
Time method adjusted to increment time values in
seconds.
Figure 5.3. End User evaluation..
As a result of the end user evaluation, the developer was made aware a few improvements that could
be implemented in the remaining timescales. Features that couldn’t be added have been pushed into
the future enhancements scope. The advantage of this kind of evaluation method is that it has
presented the developer with a list of improvements that the customer and not the developer, feel are
necessary. It has also provided expert feedback from somebody who is very knowledgeable in the
46
underlying principles of the model and as such has the ability and authority to spot mistakes in the
visualisation behaviour.
4.6 Functionality versus Efficiency
As a result of end user testing and the formative evaluation it became apparent that there were several
trade offs between system functionality and efficiency. [Figure 5.4.1] and [Figure 5.4.2] show the
respective loading times and visualisation speed for the initial structured solution and the final
unstructured solution
Loading Times (mins:secs) FPS
System Sample Set
1 2 3 1 2 3
40x40 base grid with 2 levels of
refinements and 21 timeframes. 2:10 2:28 9:30
12
minimum
6
minimum No run
40x40 base grid with 3 levels of
refinements and 26 timeframes. 6:58 7:43 No load
5
minimum
2
minimum No run
30x30 base grid with 2 levels of
refinement and 101 timeframes 11:34 13:00 No load
12
minimum
6
minimum No run
Figure 5.4.1. Test results for initial structured solution.
Loading Times (mins:secs) FPS
System Sample Set
1 2 3 1 2 3
40x40 base grid with 2 levels of
refinements and 21 timeframes. 0:40 0:55 3:40
60
minimum
20
minimum
5
minimum
40x40 base grid with 3 levels of
refinements and 26 timeframes. 2:48 3:13 8.23
25
minimum
15
minimum No run
30x30 base grid with 2 levels of
refinement and 101 timeframes 5:24 6:17 17:30
60
minimum
20
minimum
5
minimum
Figure 5.4.2. Test results for final unstructured solution.
System 1: Pentium IV 3Ghz Hyperthreading, 1GB RAM, Geforce4 128MB, 240GB RAID 0 IDE Hard disks.
System 2: Athlon 64 3000 (1.8Ghz), 512MB RAM, Geforce6 (system memory), 80GB IDE Hard Disk.
System 3: Pentium III 700mhz, 256MB RAM, TNT2 64MB, 9GB IDE Hard Disk.
47
60FPS demonstrated the maximum frames per second the graphics card was limited to. Even when all
the drawing methods were switched off and only the toolbar was visible, the card could only achieve a
maximum 60FPS so it can be assumed that OpenGL or the hardware drivers limit the card to this
when faster speeds are required. A ‘No run’ occurred when the hardware refused to display anything
of any use. In the case of both solutions it was that rotation and placement manipulation proved so
slow and jerky as to be completely unusable. A ‘No Load’ occurred when loading the files took so
long it wasn’t worth continuing the test (25mins +).
The results from the tests show clearly that there is a correlation between the number of mesh
refinements and the speed at which the graphics card is capable of regenerating the display. As mesh
refinements are added, the number of vertices plotted, rises by a factor of 4 (in worst case scenario).
Any simulation beyond 4 levels of refinement becomes very large in terms of data and becomes
difficult to visualise on standard resolution monitors with vertex points and line edges merging into a
see of solid black. [Moller, 2002] states that for completely smooth and jerk free visualisation, a
system should perform at a speed between 65-80 FPS but that anything above 20FPS is sufficient.
The tests also highlighted the importance of the CPU, especially in lowering loading times as with a
storage system at least twice as fast as system 2 but with a similar speed of CPU, system 1 was only
able to load the output files marginally quicker. The slow results for the Geforce 6 card over the
Geforce 4 card are explained by the fact that the Geforce accelerator is an onboard graphics chip with
no dedicated memory (built into the motherboard) and therefore has to use the slower system
memory. This would also explain why the card did not take advance of the Vertex buffer object
functionality.
48
5. Conclusion
5.1 Successes
All the minimum requirements were met, if not in the way originally intended [Section 4.2] and the
final solution did offer an improvement in visualisation and interactive techniques over the
preliminary work done in Matlab [MathWorks, 2006]. A good choice of methodology and a sturdy
development plan was fundamental in producing an appropriate and valuable solution within the
timescales of the project.
5.2 Failures
The project failed to implement a working quadtree structure however this didn’t prevent the final
solution from meeting all the minimum requirements. Ideally a quadtree would be used to allow
control over the levels of mesh refinement but this feature would be considered as a future
enhancement. The solution also fails to implement the Vertex Buffer Objects under the SOC Linux
environment although it does work on different versions of Linux outside of the university. The
probable cause within the SOC is missing libraries files or the use of an older OpenGL release that
does not fully support the VBO functionality. Both of these problems are ‘out of the hands’ of the
developer, however the use of VBOs under the Linux environment is not of top priority as it was not
originally part of the project scope.
5.3 Future Enhancement Possibilities
The main extension to the project would be the implementation of a working quadtree. Ideally the tree
would store the structured OTT-2D output data efficiently, while displaying a correct mesh of
multiple resolutions. The tree would provide a mesh of multiple refinements with no overlap or gaps
and provide functionality to the user to control the number of mesh refinements visible, with the
option to add and remove them as required.
Another important consideration, would be to re-design the initial OTT-2D output file reading and
storage routines, to dramatically increase the speed at which it performs and to add functionality that
allows the application to query the user as to the location of the files to be processed. It would also be
possible for the application to scan the input file directory and to obtain the number of files to be read
in without the need for the user to enter the required amount. As an addition to the file loading
functionality, the application could be rewritten to include commands to load in new sets of data files
without the requirement to exit and re-load the entire application.
49
The project could also be enhanced by fixing the current list of unfinished functionality which
comprises of the requirement of directional arrowheads on the velocity vectors and the ability of the
scene to cast self shadows via functionality available in the stencil buffer.
As a result of the heuristic evaluation, it became clear that users would benefit from a help library,
direct linked and accessible from the visualisation toolbar and the inclusion of a screen dump utility
that the user would be able to utilise to take and save snapshots of the simulation.
5.4 Evaluation of Decisions Made
Towards the end of the project, it became apparent that after several failed attempts and several weeks
of research and coding, the likelihood of finishing a working quadtree implementation was very
unlikely. Rather than risking the chance that the minimum requirements would not be met in at least
one area, it was decided that focus should switch to finding a different approach. The alternative
method presented, was the opportunity to utilise the unstructured files from the OTT-2D conversion
scripts, which ultimately lead to the construction of a solution that met and exceeded the minimum
requirements [Section 1.3]. While credit for the conversion scripts is entirely due to the author
[Hubbard, 2002], the switch to the unstructured output allowed the project to progress without
stagnating and loosing too much momentum. The switch in direction also gave the opportunity to
evaluate the old and new solutions side by side and to compare the functionality and efficiency
offered by both the structured and unstructured files.
It is difficult to determine if the OpenGL route was a better choice than choosing the Matlab or Iris
Explorer options but there was certainly a lot more features to be utilised in the OpenGL libraries than
was ever envisaged at the start of the project. Choice of the GLUI toolkit proved to be a good decision
as the user interface scored highly in the usability and heuristic evaluations.
5.5 Overall Methodology Evaluation
In choosing the RAD (Rapid Application Development process) methodology, there was the inherent
risk that the required features would be pushed out of scope and that with rapid prototyping the
scalability would be reduced. With the RAD approach, the developed application started as a
prototype and evolved into the finished application thus making it potentially difficult to incorporate
addition features not captured by the minimum requirements. However, this turned out not to be the
case and instead the fast nature of the RAD, helped to get the project back on track when the initial
solution reached a premature end [3.4 Phase 2]. For this reason, the methodology turned out to be
potentially the best option as when compared to waterfall and spiral methods focus was kept to
satisfying the core requirements first, and did not get bogged down in endless iterative design, build
and test cycles.
50
References Abel, T., (2006). Jacques: Enzo's best friend. http://www.astro.psu.edu/users/tabel/Jacques/ [28th April
2006].
Berger, M.J., Colella, P., (1989). Local adaptive mesh refinement for hyperbolic partial differential
equations. J. Comput. Phys. 82, 67-83.
Berger, M.J., Oliger, J., (1984). Adaptive mesh refinement for hyperbolic partial differential
equations. J. Comput. Phys. 53, 484-512.
Bhola, H. S., (1990). Evaluating "Literacy for development" projects, programs and
campaigns: Evaluation planning, design and implementation, and utilization of evaluation
results. UNESCO Institute for Education. xii, 306 pages.
Bowman, D., Kruijff, E., LaViola, Jr, J. J., and Poupyrev, I. (2004) 3D User Interfaces: theory
and practice. Addison Wesley.
Browne, J.C., Parashar, M., (2006). DAGH: Data-Management for Parallel Adaptive Mesh-
Refinement Techniques. CAIP Center & Department of Electrical and Computer Engineering.
Bryan, G., et al., (2006). Enzo, Cosmological Simulation Code, General Information.
http://cosmos.ucsd.edu/enzo/ [28th April 2006].
De Waal, J.P., Van Der Meer, J.W., (1992). Wave run-up and overtopping on coastal structures. Proc.
23rd Int.Conf. Coastal Eng. A.S.C.E., Venice, pp. 1758-1771.
Dodd, N., (1998) . A numerical model of wave run-up, overtopping and regeneration. A.S.C.E
J.Waterw. port. Coat. Ocean Eng. 124 (2), 73-81.
Dix et al., (2004). Human Computer Interaction 2nd Ed. Prentice Hall.
Hubbard, M.E., Dodd, N., (2002). A 2D numerical model of wave run-up and overtopping. Elsevier.
Coastal Engineering 47 (2002) 1-26.
Hubbard, M.E., Dodd, N., (2000). ANEMONE : OTT-2D, A User Manual (Version 1). HR
Wallingford. Report TR 65.
51
Finkel, R.A., Bentley, J.L., (1974). Quad Trees: A Data Structure for Retrieval on Composite Keys. Acta Informatica, 4:1-9.
Haines, E., Akenine-Moller, T., (2002). Real Time Rendering 2nd Ed. Ak Peters.
Israel, R., (2002). Richardson Extrapolation. http://www.math.ubc.ca/~israel/m215/rich/rich.html
[12th April 2006].
Jenkins, T., (2003). How to Program Using C++. Palgrave Macmillan.
Klein, R.I., Fisher, R., McKee1, C.F., (2004). Resolution Issues in the Collapse and Fragmentation of
Turbulent Molecular Cloud Cores. RevMexAA (Serie de Conferencias), 22, 3-7 (2004).
Lachance, B., (2005). Développement d'une structure topologique de données 3D pour l'analyse de
modèles géologiques. Maître ès sciences (M.Sc.). Université Laval.
Lawlor, O.S., Kalé, L.V., (2001). Supporting Dynamic Parallel Object Arrays. ISCOPE, Stanford,
CA.
Manual on the Use of Rock on Coastal and Shoreline Engineering (MAN), 1991. Construction
Industry Research and Information Association and Centre for Civil Engineering Research and Codes.
MathWorks, (2006). MATLAB® - The Language of Technical Computing.
http://www.mathworks.com/products/matlab/ [24th April, 2006].
NAG, (2006). Iris Explorer. http://www.nag.co.uk/welcome_iec.asp [24th April, 2006].
Nielsen, J., (1994). Enhancing the explanatory power of usability heuristics. CHI '94:
Proceedings of the SIGCHI conference on Human factors in computing systems, ACM
Press, pp 152-158.
Nielsen, J., Molich, R., (1990). Heuristic evaluation of user interfaces, Proc. ACM CHI'90
Conf. (Seattle, WA, 1-5 April), 249-256.
Paul, B., (2006). The Mesa 3D Graphics Library. http://www.mesa3d.org/ [24th April, 2006].
52
Philips, L,. (2002). Trick 14 - Space Partitioning with Octrees, Game Programming Tricks of the
Trade. Premier Press.
Quirk, J., (1991). An adaptive grid algorithm for computational shock hydrodynamics. PhD thesis,
College of Aeronautics. Cranfield Institute of Technology.
Quirk, J.J., (1994). A Cartesian Grid Approach with Hierarchical Refinement for Compressible
Flows. Institute for Computer Applications in Science and Engineering, ICASE Report No. 94-51.
Rademacher, P., (1999). GLUI. A GLUT-Based User Interface Library. User manual.
http://www.cs.unc.edu/~rademach/glui/src/release/glui_manual_v2_beta.pdf [24th April 2006].
Rademacher, P., (2006). GLUI interface library. http://www.cs.unc.edu/~rademach/glui/ [24th April
2006].
Redbook, (1994). Appendix F Calculating Normal Vectors. Addison-Wesley Publishing.
SGI. (2006). OpenGL Overview. http://www.opengl.org/about/overview/ [24th April 2006].
Skillsoft, (2003). OpenGL Code InstantCode: Advanced Graphics. Skillsoft
Titov, V.V., Synolakis, C.E., (1995).Modelling of breaking and non-breaking long-wave evolution
and run-up using VTCS-2. A.S.C.E J. Waterw. Port Coast. Ocean Eng. 121 (6), 308-316.
Titov, V.V., Synolakis, C.E., (1998). Numerical modelling of 3D long wave run-up. ASCE J. Waterw.
Port Coast. Ocean Eng. 124 (4), 157-171.
Tremblay, C., (2004). Chapter 16 - Space Partitioning: Cleaning Your Room, Mathematics for Game
Developers. Course Technology.
Wright R.S., Sweet, M., (2000). OpenGL SuperBible, Second Edition. Waite Group Press.
53
Accompanying Material A CD-ROM containing the visualisation user manual, several test run output files and the project
executables, libraries and source code, is available for Matthew Hubbard (School of Computing,
University of Leeds, UK).
Online images and videos of the simulations are available at:
www.personal.leeds.ac.uk/~scs2atw/fyp/
54
Appendices Appendix A Personal Reflection Throughout the course of this project, I have had the chance to show intuitiveness and demonstrate
initiative in tasks that proved to be both academically challenging and rewarding. It has offered me
the opportunity to undertake an individual project on a scale of which I will probably never again be
able to attempt and demonstrates the accumulation of 4 hard years study for a Computing Degree at
Leeds University. Researching the topics and building the final solution for this report has been an
enjoyable although at times frustrating, experience, that I hope I can look back on for inspiration and
support in my future career.
Over the course of the project, I feel that there have been many lessons learnt, two of the most
important being, the lack of a diary to make notes at convenient times and spending too much time on
the programming element of the project and neglecting the written report early on. I would there fore
suggest:
Keep a diary
Unfortunately this was something that I didn’t thing to use until the well into the implementation
stages of the project. Many a flash of inspiration was forgotten, as my memory tried to cope with
confusing theories and formulae. My advice would be to buy a small diary or pad and carry it around
with you at all times. There is nothing worse than knowing you had the answer but now, you just can’t
quite remember it.
Do not get carried away with the programming side of the project.
Everybody wants to build the latest and greatest, but remember, no matter how good it is it will only
get you a maximum of 20 out of 100 for the entire report. I fell into this trap, hurried trying to cram in
more and more improvements when really I should have been concentrating on the report.
Other helpful suggestions that I think people should consider before undertaking a project are:
Pick a subject you will enjoy.
If you don’t pick a subject you have a personal interest or feel particularly attracted to, then it is
unlikely that you will show enough commitment. When the deadlines start to approach and you
suddenly realise how much work is left, will you still have enough interest to stay up late working to
get it done?
55
Respect the people that offer you help.
Do not go looking for help and expect answers straight away. Nobody is going to sit and code your
project for you and people will be unwilling to help at all if you don’t show that you have at least tried
to solve or understand the problem. Leaving it late in the day to seek help with problems is also a bad
idea. Remember that if people offer to help you will have to patient. If they are spending their free
time to help you, then it is courteous to allow them to do it in their own time and not to be rushed by
you.
Behave professionally when dealing with the client
If you undertake a project that requires regular communication with a client, then remember to be
professional and polite at all times. This is an excellent opportunity to experience the interactions
between client and consultant, similar to that of a real company. Remember that the client will know
you are a student but won’t necessarily need to be reminded with scruffy clothes or lack of
punctuality. In the real world of work, you won’t keep clients for long if you show disrespect by
turning up late or not delivering work to schedule.
56
Appendix B Initial project plan:
57
Final project plan:
58
Appendix C Test Plan (Abridged).
A short section of the test plan:
Test Case Outcome Pass/Fail Fixed
Correct output file is found?
Application finds the first OTT-2D file and loads it correctly
Pass
Fixed – Extra 0 character found in input stream.
Correct sequence of files is found?
Application does not load OTT-2D files in correct sequence
Fail – Loads first 9 files only
Only loads files that are available, no matter how many are requested?
Application only loads the files that are available. User is alerted that files requested do not exist if they aren’t available in the immediate directory
Pass
Displays error message when incorrect number of files are loaded?
Correctly displays an error message informing the user that the number of files they have entered is incorrect.
Pass
Application loads full screen? Application loads full screen Pass
‘Exit’ button terminates application on single press?
Application terminated on pressing ‘Exit’ Button Pass
Scene rotation occurs when mouse button held down?
Scene only rotates when mouse button is not pressed. Fail
glutPassiveFunc replaced with glutMotionFunc
Scene is scaled appropriately on a widescreen display?
No, scene is stretched horizontally. Fail No fix implemented
Scene rotation is not limited to 360 degrees
Scene rotation goes beyond 360 degrees. Pass
59
Appendix D Visualisation User Manual (Windows)
Requirements:
• The GLUT libraries are installed on your system. If not, copy the file glui32.dll from the CD-
ROM and place in your system directory
$:\windows\system\ (where $ is your primary drive).
GLUT is already installed on the SOC Linux and Windows machines
• Unstructured output files present in same directory as mesh.exe executable
To Run:
• Simply double click the mesh.exe file and enter the number of output files to be processed
when prompted. After loading the files, the visualisation will load up as full screen.
Functionality:
• To run the simulation press the ‘Run’ button at the top right of the toolbar.
• To slow down and speed up the simulation use the increment/decrement slider (This only
works before and after the simulation has been run and not during!)
• To rotate the scene, press and hold the left mouse button and then move the mouse to control
the rotation. Optionally you can use the arcball rotation control on the toolbar.
• Scale the visualisation by click and dragging over the scale button
• Position the visualisation by click and dragging over the position button
• Pan the visualisation by click and dragging over the pan button
• Add or remove, seabed, water surface, transparent water and velocity vectors by sing the
check boxes.
• Convert to wireframe and anti-aliased wireframe by using the checkboxes provided.
Quit
• The visualisation can be terminated at any time by selecting the ‘Quit’ button.
60
Appendix E GLUI feature list
The following is a complete list of the GLUI features, taken directly from the GLUI website [##].
• Complete integration with GLUT toolkit
• Simple creation of a new user interface window with a single line of code
• Support for multiple user interface windows
• Standard user interface controls such as:
Buttons
Checkboxes for Boolean variables
Radio Buttons for mutually-exclusive options
Editable text boxes for inputting text, integers, and floating-point values
Spinners for interactively manipulating integer and floating-point values
Static text fields
Panels for grouping sets of controls
Separator lines to help visually organize groups of controls
• Controls can generate call-backs when their values change
• Variables can be linked to controls and automatically updated when the value of the control
changes
• ("live variables")
• Controls can be automatically synchronized to reflect changes in live variables
• Controls can trigger GLUT redisplay events when their values change
• Layout and sizing of controls is automatic
• Controls can be grouped into columns
• User can cycle through controls using Tab key
61