Background
As part of my final year of my degree I had to work alongside another finalist on a Physics project.
After successfully completing the Fortran course and subsequently learning some C, I expressed my desire to work on a programming related project to my tutor. The idea for the Druantia project was introduced to me as “Write a program using an existing flight simulation library to visualise Mars.” My initial reaction was quite simply “Wow! That sounds really interesting.”
Upon commencing the task in October 2005, myself and Robert Dowse were introduced to our project supervisor, Dr Jörn Wilms. Jörn had decided to split the task into two sections – a 2D topographic colour map and a real-time 3D terrain visualisation.
Druantia 2D
Rather than dealing with the Mars MOLA ’128 samples per degree’ data from the outset as the data set is considerable in size (~2GB in total), we used the ETOPO-2 2-minute gridded set for Earth (~100MB). Also, one of the major design goals was to be able to add the data for a new planet with minimal time and effort. This concept was proven through the addition of the necessary extra functions for the MOLA data in just a few hours.
The problem was decomposed into a set of functions which were delegated between Jörn and the two of us. As my programming experience with C, while minimal, was greater than Rob’s, I took on the bulk of the programming and Rob worked on the maths theory of the map projections. As it was by far the largest piece of code I had written to date, it appeared a very daunting task but in hindsight it seems so simple.
The basic layout of the program was based around the concept of a view window similar to what one is presented with when using Google Maps. A few basic parameters are provided to the program, each pixel’s position is converted into a surface coordinate via the map projection functions, the corresponding altitude is read from the data and converted to a colour via linearly interpolating between two colour thresholds. The thresholds for Earth are well-defined and a fairly realistic image can be created from such a simple process. For the Mars MOLA data, some thresholds and colours were defined to accentuate the terrain but they don’t portray anything more.
Druantia 3D
Using the OpenSceneGraph library provided us with a simple OpenGL API and offered a pre-designed object that we could use to take a similar functional design to the 2D program.
The HeightField object is a 2D array of height values defining vertices to be connected by a simple mesh. The object is designed for collision deformation calculations among other things, hence the lack of mesh optimisation which we later found to be a performance issue, coupled with the significant impact of unnecessary collision detection. This approach produced some impressive results.
The original idea to allow navigation of the entire planet without requiring the user to exit the program, input new position parameters and reinitialise the program was to use threaded regeneration in the background based on horizon thresholds. This technique would be quite complex to write for someone not so experienced in the programming world such as myself.
Beyond…
I have become aware that the project is to be continued next year by two more finalists (most likely two of my coursemates who are doing Masters courses) though it will take a different direction. After some research into terrain rendering from topographic and photographic data it has become apparent that a relatively new method is very successful on modern hardware.
The data are preprocessed into tiled terrain/photo databases and then the tiles are fed into a viewer based on how many tiles can be reasonably displayed at one time. The control over the amount of data being read and the number of polygons in view produces a more consistent framerate. The osgdem application can be used to process data in such a way.
As part of the OSSIM project some people had a similar idea to use this terrain database technique coupled with the OpenSceneGraph library, distributing the tile data via a network connection of some description, or using local data. osgPlanet in its original and ‘current’ incarnation is capable of processing raw data into tiles on-the-fly as well as many other interesting features. The project has received some funding to develop a more robust and optimal solution has led to osgPlanet2 which should be in a reasonable state by the end of the summer months of 2006. I hope it is developed enough to be used as the basis for the continuation of the planetary visualisation project undertaken this year. I consider Druantia a prototype of an idea that produces great-looking results but isn’t particularly usable. I look forward to assisting next year’s developers and involving myself in further development work in this area.