About The Dataset
Visualisation Considerations
Visualising the data in AVS
Topography
Temperature
Relative Humidity
Wind
Generating the field files
Creating an animation in AVS
Visualising the data in C + OpenGL
Converting the binary data to ASCII
While I am not familiar with the source of the data, I am aware that the dataset was used by Wei Wang as a part of her research at Vislab. The data consists of several files, each containing a different dependent variable, plus a file containing (x, y, z) co-ordinates for each data point. The dependent variables were height for topography, as scalars in the z=0 plane, temperature and relative humidity as scalars at each (x,y,z) co-ordinate, and wind velocity as 3d vectors, each with it origin at an (x,y,z) co-ordinate. Each of the files contains the data for 24 discreet time intervals, each corresponding to a 1 hour step over a 24 hour period. The starting (and hence finishing) times are not known, however I beleive the data was aquired on the 12th of april 1997.
The topographical data was stored in ascii format, with white-space separated floating point numbers. The temperature and relative humidity data were stored in a binary format, with every 4 bytes corresponding to a data value. The wind velocity and co-ordinate data was also stored in a binary format, with each vector defined by 3 four-byte floating point numbers. The binary data is believed to be stored in little-endian format. Each of the 24 discrete time steps were placed immediately after the previous time step's data, in the same file. There were four bytes of unused data at the start of each file.
During the course of creating the visualisation in AVS, I took the opportunity to show a quicktime movie of the visualisation to some aquaintances in order to show them what I had been working on, and asked them about how they were interpreting the data. What I found was that their intuition was that the topography was colored by temperature, and wind vectors by magnitude. At that stage of development however, the topography was colored by altitude, and wind vectors by temperature. They had no trouble interpreting relative humidity data in the form of white iso-surfaces.
Although coloring the wind vectors by temperature displayed the correlation between temperature and wind velocity, I decided at this point that it would be better to reduce the likelihood of misinterpreting the data. In keeping with this decision, I changed the topography coloring to represent temperature, and the wind vectors coloring to correspond to wind speed.
The Topography data was found in a 2d dataset with a single dependent variable - height. The obvious choice, given the nature of the data, was to use the AVS field to mesh module to convert the data into a three-dimensional surface, which can be immediately recognised as topographical data. Lighting was used to improve the impression of depth and perspective, because the mesh was not colorised by height.
Because the field to mesh module generates mesh data which is centered around the x-y plane (ie. z=0), the data was offset to prevent the topography from intersecting the relative humidity data, due to the mesh's exageration in the z dimension.
Temperature was visualised solely by overlaying the temperature data on the topography. While this does not make complete use of the data available, it is a neccesary concession in order to produce an uncluttered visualisation. Other visualisation methods such as coloured spheres, and colored wind vectors were trialled, however coloring the topography by temperature yielded the best compromise.
Colorising the topography was achieved using the colorize geom module, which, as it's name suggests, adds a colourmap to AVS geometry data. A color scale was also added using the same colormap, providing a method of reading quantitative data from the visualisation.
The relative humidity data was visualised using the AVS isosurface module. The isosurface was made white, and given a constant transparency so that it did not obscure the other data. The decision to use an isosurface to represent the data was largely influenced by previous visualisations of weather datasets we had seen. Interpretation of the isosurface is simple, and easily recognisable as clouds. Further investigation during the development of the visualisation however shows that there are alternatives to the isosurface technique, such as using the humidity data to vary the alpha luminance channels.
Wind was visualised using the hedgehog module to generate vectors in the form of 'arrows'. The length of the arrow was determined by using the output of the vector mag module, which calculates the magnitude of the vector data, and corresponds to wind speed in knots. The 'arrows' were then colored by the vector magnitude produced by the vector mag module, using the color range module. The output of this module was then used to generate a scale for the wind data. The "tube" module was used to convert the arrows in the form of lines, into three-dimensional arrows which were easier to see.
Animating the dataset in AVS was acheived by coupling the animated integer module with several animate filename modules, each with a corresponding read field module. This allowed the dataset to be read in a sequence of 24 files each for relative humidity, temperature and wind velocity, which the topography data remained constant. For each of the 24 datasets, the rendered image was written to disk using the write any image module.
The 24 images output by AVS to disk were then loaded into sgi's movieconvert utility and converted to a quicktime movie, at 2 frames per second to create a coarse animation of the 24 hour period.
Due to the nature of the dataset, in order to read in the 24 time steps for animation, it was neccesary to create one field file for each type of data, for each time step. Rather than manually create these 120 field files, a series of unix shell scripts were created which automatically generate the required field files for use by AVS.
While the details of the code is beyond the scope of this document, the scripts can be found here, in tar-ed, gzip-ed format. The main script can be envoked by typing ./make,
After visualising the data in AVS, I decided to write a visualisation program in C using the OpenGL graphic library, and glut, the free GL Toolkit, which handles programming details such as window creation and user input etc.
After converting the data to ascii format, I had to decide on some algoritms for converting the dataset into polygons which OpenGL could draw. The first algoritm I wrote was the equivalent of the field to mesh module in avs, which converted the topography data, (an array/grid of height values), into a 3d mesh of triangles.
Triangles were used because they are always convex and co-planar, which makes them easier to render in OpenGL. (Though OpenGL does support arbitrary polygons, they must be co-planar, so using triangles means this property always holds.)
After rendering the topography, I decided to render the relative humidity data, which is potentially far more algorithmically challenging. Initially I intended to create an isosurface by implementing the Marching Cubes algorithm, however after seeing how complex the algorithm would have been to write, I decided instead to write a marching squares algorithm, since there are only 16 cases to consider, rather than the 256 cases for a marching cubes. Therefore, I used the marching squares algorithm on horizontal slices of data in order to generate 'clouds' using the relative humidity data.
Upon completing the marching squares algorithm, I was unhappy with the results, so I explored other methods. I found that to realistically render the cloud data, the best method was to use OpenGL's alpha blending function, and give each point an alpha (translucency) value which was proportional to it's relative humidity value. In addition to this, each point was given a grey value in the range white through black, with low relative humidity shown in white, and high relative humidity shown in black. Using several layers of relative humidity data in this fashion gave quite convincing cloud patterns.
The C renderer is capable of rendering and animating the 24 hour period while providing real-time user interaction. This allows the user to do a full "fly-through" along the terrain while the clouds data is rendered. Of course, this requires either a very powerful CPU, or hardware OpenGL acceleration.
The source the the renderer can be found here. This code is available for marking purposes only, and should not be used in any way without the permission of the author, Luke Macpherson. Permission is granted to employees and students of VisLab and the University of Sydney to use the code for non-commercial purposes, if due credit is given to the author.
In order to convert the binary data files into ascii files, I wrote a small c program which converted the binary data into a series on ascii floating point numbers by reading the data 4 bytes at a time, correcting for big/little endian systems by shuffling the byte order, and writing the data out using printf().
This program made the data much simpler to read in, and also made the data much more portable, since I was moving between a sun machine (big-endian) and a pc (little endian).
A copy of the C source code, readbin.c is available for download.